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The  ISI  program  consists  of  eight  research  areas;  Program  Verification  -- 
logical  proof  of  program  validity;  Programming  Research  Instrument  — 
development  of  a major  time-shared  microprogramming  facility;  Spec i f icati on 
Acquisition  From  Experts  — the  study  of  acquiring  and  using  problem 
knowledge  for  making  informal  program  specifications  more  precise; 

Protection  Analysis  — methods  of  assessing  tne  viability  of  security 
mechanisms  of  operating  systems;  Information  Automation  — development  of  a 
user-oriented  message  service  for  large-scale  military  requirements; 

Network  Secure  Communication  — work  on  low-bandwidth,  secure  voice 
transmission  using  an  asynchronous  packet-switched  network;  Special  Projects 
— a variety  of  activities  and  hardware  developments  in  support  of  Institute 
programs;  and  ARPANET  TENEX  Service  — operation  of  TENEX  service  and 
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I I This  report  summarizes  the  research  by  USC/Information  Sciences  Institute  from 

I I 1 July  1975  to  30  June  1976.  The  research  is  aimed  at  applying  computer  science  and 

^ [ technology  to  problem  areas  of  high  DoO/military  impact. 


The  ISI  program  consists  of  eight  research  areas:  Program  l^eri/ication— logical  proof 
of  program  validity;  Programming  Restareh  //»trument--development  of  a major 
time-shared  microprogramming  facility;  Specification  Acquisition  From  Experts— ihe  study 
of  acquiring  and  using  problem  knowledge  for  making  informal  program  specifications  more 
precise;  Protection  methods  of  assessing  the  viability  of  security  mecnanisms  of 

operating  systems;  Information  /^tomatton—development  of  a user-oriented  message 
' service  for  large-scale  military  requirements;  Network  Secure  Communication— v/ork  on 

low-bandwidth,  secure  voice  transmission  using  an  asynchronous  packet-switched  network; 
Special  Projects— a variety  of  activities  and  hardware  developments  in  support  of  Institute 
programs;  and  ARPANET  TENEX  Service—operation  of  TENEX  service  and  continuing 
development  of  advanced  support  equipment. 
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EXECUTIVE  OVERVIEW 


Thb  information  Sciences  Institute  (ISO,  a research  unit  of  the  University  of  Southern 
California’s  School  of  Engineering,  was  formed  in  May  1972  to  perform  research  in  the 
fields  of  computer  and  communications  sciences  with  an  emphasis  on  systems  and 
applications. 

A close  relationship  is  maintained  with  USC  academic  programs  through  active 
cooperation  among  the  Institute,  the  School  of  Engineering,  the  Department  of  Electrical 
Engineering,  and  the  Computer  Science  Department.  Ph.D.  thesis  supervision  is  an  integral 
part  of  tSI  programs,  as  is  active  participation  of  research  assistants  supporting  ISI 
projects.  ISI  staff  members  frequently  direct  or  participate  in  nationwide  and  international 
meetings  and  conferences;  the  institute  also  hosts  frequent  colloquia  and  seminars  as  a 
forum  for  distinguished  speakers  from  other  organizations. 

The  character  and  uniqueness  of  ISI  are  expressed  in  the  foil.jwing  objectives: 

• A major  university-based  computer  science  rese?rch  center. 

• A center  with  a largely  full-time  staff  of  researchers,  augmented  by 
graduate  students  and  faculty. 

• A center  which  possesses  a unique  blend  of  basic  research  talent  and 
application  and  system  expertise.  The  last  two  attributes  are  of  special 
significance  to  the  application  of  computer  science  and  technology  to  key 
military  problems. 

• A university-based  research  center  with  strong  active  ties  to  the 
U.S.  military  community  and  a strong  leadership  role  in  identifying  key 
computer  R&D  requirements  in  support  of  long-term  military  needs. 


The  Institute  is  structured  to  provide  research  and  development  capability  at  the 
system  level— often  required  tc  assure  an  understanding  of  real  problems  and  to  provide 
useful  solutions  in  trcnsferable  form.  Project  leaders  share  visibly  in  the  responsibility 
for  the  conduct  of  each  project  and  for  the  quality  and  impact  of  the  research.  At  the 
end  of  the  fourth  year  of  operation,  the  full-time  professional  research  staff  numbers  43. 
The  total  number  of  iSI  employees—including  full-time  research  staff,  participating  faculty 
and  graduate  students,  and  support  personnel— is  85. 
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EXECUTIVE  OVERVIEW 


The  activities  of  ISI’s  eight  major  areas  of  research  and  associated  support  projects 
are  summarized  briefly  below.  Some  of  the  research  projects  reported  in  this  document 
are  discrete  activities  in  themselves;  others  can  be  seen  as  parts  of  a larger  whole.  For 
example,  Program  Verification,  Specification  Acquisition,  and  the  Programming  Research 
Instrument  projects  should  be  considered  as  individual  parts  of  an  overall  research  effort 
in  Programming  Methodology;  Irformatior  Automation,  Network  Secure  Communicatic  i,  and 
Special  Projects  are  linked  elements  of  a major  investigation  into  Network  Communications 
Technology.  These  mutual  interdependencies  among  the  various  projects  at  ISI  contribute 
largely  to  the  fruitfulness  of  the  Institute's  research  activities. 

Program  Verification.  The  goal  of  program  verification  research  at  ISI  is  to  develop 
an  effective  program  verification  system  for  proving  that  computer  programs  are 
consistent  with  precisely  stated  detailed  specifications  of  what  the  programs  are  intended 
to  do.  The  system  is  expected  to  replace  significant  parts  of  testing  in  current  software 
development,  and  will  also  provide  important  tools  for  developing  and  judging  the  success 
of  new  programming  language  designs,  new  programming  methodologies,  and  new  detailed 
specification  techniques.  Already  running  at  ISI  is  an  initial,  experimental  version  of  an 
interactive  program  verification  system  whose  design  philosophy  is  to  provide  automatic 
assistance  for  the  verification  process  where  practical,  and  otherwise  to  rely  on  human 
int"  .action.  The  system  has  verified  numerous  example  programs.  Important  progress 
has  been  made  in  the  following  areas:  improved  user  environment  and  interface  to  the 
verifier,  extensible  verification  generator,  algebraic  approach  to  data  abstractions  including 
their  verification,  and  influence  of  verification  on  language  design.  The  eventual  impact 
will  be  an  increase  in  the  quality  of  software. 

Programming  Research  Instrument.  PRIM  is  an  interactive  microprogrammable 
environment  used  for  the  emulation  of  existing  or  newly  specified  computer  systems  with 
major  emphasis  on  providing  debugging  tools.  These  tools,  available  via  NSW,  provide  the 
users  with  more  powerful  debugging  facilities  than  available  in  the  original  target 
computer  systems.  The  facility  consists  of  a powerful  microprogrammable  computer 
(MLP-900),  closely  coupled  to  a TENEX  operating  system,  and  software  to  permit  users  to 
create  and  debug  new  emulators  and  target  sy..tems.  Two  prototype  emulators,  the 
Lh'K-20  and  the  U1050,  have  been  completed  and  have  been  integrated  into  NSW.  PRIM  is 
an  attempt  to  generalize  a solution  to  the  problem  of  software  development  through  the 
use  of  emulation  tools. 


Specification  /Icquisition  From  Experts.  The  major  effort  of  the  SAFE  project  is 
simpiy  to  allow  users  who  are  not  computer  programmers  to  functionally  specify  their 
application  directly  to  a computer  system,  with  the  system  transforming  this  input  into  a 
precise  functional  specification  of  the  application.  This  system  is  intended  to  be  both 
independent  of  any  particular  problem  domain  ancf  able  to  deal  with  "loose"  ,'i.e., 
incomplete,  inconsistent,  etc.)  problem-oriented  descriptions  of  a domain  through  a 
dialogue  with  the  user.  From  this  dialogue  the  system  can  acquire  the  "physics"  (the 
objects,  laws,  relationships,  etc.)  of  the  loosely-defined  domain,  structure  it,  and  use  it  to 
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EXECUTIVE  OVERVIEW 


IX 


understand  further  communication  and  finally  to  rewrite  the  specification  in  precise 
operational  form.  The  system  is  being  developed  in  the  context  of  a simplified  real-world 
military  specifications  manual.  An  informal,  incomplete  specification  for  first-level  message 
distribution  has  successfully  been  converted  to  a precise  operational  form.  The  system  is 
now  being  expanded  to  deal  with  more  complex  specifications. 

Protection  AnalytU.  The  goal  of  this  project  is  to  develop  efficient  techniques  and 
sem  omated  tools  for  detecting  in  operating  systems  various  types  of  protection  errors, 
i.e.,  errors  that  allow  the  systems  to  be  compromised.  The  approach  is  empirical,  based  on 
the  observations  that  (1)  protection  errors  fall  into  a limited  number  of  distinct  classes  and 
(2)  techniques  can  be  developed  for  finding  the  errors  associated  with  each  class.  The 
method  is  to  collect  a data  base  of  known  errors,  use  it  to  determine  the  error  classes, 
and  (for  each  class)  identify  the  relevant  error  characteristics  for  the  purpose  of 
developing  an  effective  search  algorithm.  To  date,  errors  from  a variety  of  systems  have 
been  collected  and  techniques  for  finding  errors  for  three  of  the  classes  have  been 
reported.  The  project  proposes  to  analyze  and  report  on  the  remaining  seven  error 
classes. 

Information  Automation,  The  Information  Automation  project  lias  a dual  goal;  1)  to 
develop  the  technology  for  providing  on-line  computer  services  directly  to  untrained  users 
and  2)  to  develop  a secure,  on-line,  interactive  writer-to-reader  message  service  for  the 
military  community.  Such  an  on-line  message  service,  new  to  the  military,  provides 
interactive  assistance  for  formal  messages  from  the  initial  draft  preparation  through 
coordination,  transmission,  and  distribution.  In  addition,  it  will  provide  informal  secure 
"off-the-record”  communication  to  reduce  the  need  for  face-to-face  meetings.  During  the 
past  year  the  lA  messagr  service  has  progressed  from  a design  on  paper  to  a 
near-operational  system.  It  is  to  be  pul  at  CINCPAC  Headquarters  on  Ohau  for  formal 
testing  in  an  operational  environment,  beginning  in  July  1977. 

Nettoork  Srourc  Communication.  The  major  objective  of  ARPA’s  Network  Secure 
lommunication  project  is  to  develop  secure,  high-quality,  low-bandwidth,  real-time, 
\ vo-way  digital  voice  communication  over  packet-switched  computer  communication 
networks.  This  kind  of  communication  is  a very  high  priority  military  goal  for  all  levels  of 
command  and  control  activities.  ISPs  role  in  this  effort  is  to  develop  efficient 
user-oriented  systems  for  digital  voice  communications,  primarily  over  packet-switched 
networks  such  as  the  ARPAN*  but  also  locally.  The  ISI  NSC  project  is  working  on 
network  voice  protocols,  digital  voice  conferencing  systems,  voice-oriented  network  host 
operating  systems,  real-time  signal  processing,  hardv/are  development,  and  other  areas. 
During  the  past  year  (1)  the  Network  Voice  Conferencing  Protocol  (NVCP)  was  developed, 
(2)  a sophisticated  local  CVSD  conferencing  system  was  implemented,  (3)  a 
signal-processor-based  demonstration  system  was  specified,  proposed,  acquired,  and  is 
being  tested,  and  (4)  the  ELF  operating  system  for  the  PDP-11  was  extensively  revamped 
and  augmented  to  form  the  EPOS  operating  system. 
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Special  Projects.  The  major  efforts  for  the  current  year  were  as  follows.  First, 
further  development  was  carried  out  on  ISI’s  and  ARPA’s  Xerox  Graphics  Printer  (XGP),  a 
high-quality  printing  capability  *n  the  form  of  a network  terminal.  Second,  131  reviewed 
technical  progress  and  provided  information  and  consultant  service  for  the  National 
Software  WorkS;  an  ARPANET-based  distributed  operating  system  that  is  intended  to 
provide  a uniform  computing  environ.nent  for  software  developers.  The  third  area  is  that 
of  providing  good  human  engineering  for  the  military  message  service  being  developed  by 
the  Information  Automation  project.  To  this  end,  ISI  is  writing  firmware  to  be  ^.sed  in  a 
modified  Hewlett-Packard  2640A  terminal.  The  goal  is  to  provide  nearly  instantaneous 
feedback  for  simple  editing  functions  and  flexibility  by  means  of  dynamic  computer  control 
of  the  range  of  available  functions. 

ARPANET  TENEX  Service.  ISI  is  supporting,  opera?  ng,  and  maintaining  three 
complete  TENEX  systems  on  a schedule  of  161  hours  per  week  each,  in  order  both  to 
provide  TENEX  service  to  ARPA  and  to  support  its  research  projects  via  the  facilities  at  ISI 
The  Institute  provides  24-hour  availability  of  TENEX  systems,  maintenance,  and  operators, 
continued  develooment/improvement  support,  support  of  the  XGP  at  IPTO,  as  well  as  ARPA 
NLS  user  support  and  minimal  NLS  software  support.  Through  this  support  we  have 
achieved  increased  long-term  up-time,  faster  repair  and  improved  preventive  maintenance, 
economy  of  scale  in  operation,  and  the  benefits  of  ISI  expertise  in  establishing 
requirements  for  optimal  loading  and  high  reliability.  In  addition,  this  experience  is  used 
to  assist  in  improving  system  reliability  and  to  increase  the  number  of  users  which  can  be 
handled  with  required  response  time. 
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GOALS  AND  IMPACT  OF  PROGRAM  VERIFICATION 

In  many  computer  application  areas  the  consequences  of  a program  not  performing 
as  intended  can  be  quite  costly  or  damaging.  The  uoal  of  program  verification  research  at 
ISl  is  to  develop  a prototype  program  verification  system  for  proving  that  programs  are 
consistent  with  precisely  stated  detailed  specifications.  With  such  a system  one  will  be 
able  to  achieve  significant  confidence  that  computer  programs  will  perform  as  intended. 
This  system  will  be  an  important  part  of  finding  solutions  to  the  manifest  problems  of 
current  software  systems— their  high  cost,  their  unreliable  behavior,  the  difficulty  of 
modifying  them,  etc.  [Goldberg73].  The  system  will  be  used  to  help  certify  that  software 
is  correct}  it  is  expected  to  replace  significant  parts  of  testing  in  current  software 
development.  It  may  be  used  in  some  cases  >o  help  determine  whether  protection  and 
security  specifications  are  met.  The  immediate  impact  will  be  that  at  last  programmers  will 
be  able  to  demonstrate  that  their  programs  meet  specifications.  The  system  will  also 
provide  impo--tant  tools  for  developing  and  judging  the  success  of  new  programming 
language  designs,  new  programming  methodologies,  and  new  detailed  specification 
techniques.  The  eventual  result  of  advances  in  program  verification  will  be  an  increase  in 
the  quality  of  software. 

Last  year’s  ISl  Annual  Report  [AR75]  contains  a description  of  the  existing 
verification  system,  named  XIVUS,  including  an  example  of  its  use.  During  the  current  year 
we  have  demonstrated  important  progress  in  the  following  areas: 

• Improved  user  environment  and  interface  to  thr>  ''erifier. 

• Extensible  verification  condition  generator. 

• Algebraic  approach  to  data  abstractions,  including  their  verification. 

• Impact  of  verification  on  programming  language  design. 

Each  of  these  achievements  contributes  to  the  overall  goal  producing  an  effective 
interactive  system  for  verifying  significant  programs  that  are  wriUen  in  several  languages 
and  that  use  current  structuring  and  decomposition  techniques.  The  results  in  each  of  the 
four  areas  are  described  sequentially  belovy. 
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IMPROVED  USER  ENVIRON^fENT 


Program  verification  is  a complex  process.  Consequently,  part  of  the  current 
verification  effort  is  aimed  at  providing  an  environment  which  is  helpful  to  the  user  whose 
goal  :s  to  verify  a set  of  programs  representing  the  solution  of  a particular  task.  During 
this  year,  three  modifications  were  made  to  the  verification  system  towards  providing  the 
desired  environment. 

1.  A new  "topievel,"  called  the  EXECUTIVE,  was  designed  and  implemented.  It  provides 

a new  command  structure  which  guides  the  user  through  the  verification  process. 

2.  A user  profile  package  was  installed  so  that  each  individual  may  "tune"  the  system 
to  his  ideas  of  how  the  verification  process  is  best  performed. 

3.  The  theorem  proving  component  has  been  modified;  it  has  a new,  simpler  command 
structure  and  records  information  used  as  the  basis  for  any  proved  theorem. 

The  additions  to  the  system  are  further  explicated  below,  including  the  specific 
motivations  for  each  addition. 


N«w  EXECUTIVE 

The  new  EXECUTIVE  was  designed  to  ease  the  user  through  the  verification  process 
(a  more  detailed  description,  including  an  extensive  transcript,  can  be  found  in  [Yonke76]). 
Several  specific  factors  were  considered  in  its  design: 

• Only  operations  which  make  sense  in  the  current  state  of  verification  are  available 
to  the  user.  For  example,  if  the  verification  conditions  have  been  generated  for  all 
the  functions  and  procedures  of  the  problem,  then  the  "GENERATE  verification 
conditions"  command  does  not  make  sense.  This  implies  that  the  available 
commands  dynamically  change  based  on  the  current  state  of  verification. 

• Item  one  should  also  apply  to  parameters  or  subcommands  of  the  system.  For 
example,  the  PROVE  command  should  accept,  as  an  item  to  prove,  only  verification 
conditions  not  already  proved. 

• The  user  of  the  XIVUS  verification  system  should  not  be  frustrated  by  giving  an 
erroneous  command  and  having  the  system  respond  with  a "do  not  understand" 
message. 

• The  system  should  always  have  a reasonable  sugge-.tion  for  the  next  verification 
step  until  the  entire  verification  process  is  complete.  Causing  the  current 
suggestion  to  be  performed  should  be  very  simple  without  impeding  in  any  way 
the  user’s  invoking  any  other  reasonable  operation  to  be  performed. 
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• The  user  should  have,  at  any  point  within  the  command  structure,  a simple  way  to 
interrogate  the  system  for  a list  of  the  next  alternative  commands  or  parameters. 

These  goals  were  achieved  by  a command  structure  which  exhibits  the  following 
characteristics: 


• Command  completion  is  similar  to  TENEX  EXEC  command  completion.  That  is,  if 
enough  characters  have  been  typed  to  disambiguate  the  command,  then  either 
typing  the  escape  key  (etc)  or  the  space  bar  (sp)  will  be  sufficient.  Typing  etc 
completes  the  command,  including  "noise  words,"  while  tp  does  not.  The  difference 
between  this  and  the  TENEX  EXEC  is  that  the  system  will  not  let  you  type  in  an 
"illegal"  character,  while  TENEX  will. 

• There  is  one  exception  to  the  completion  algorithm  described  above.  Verification 

condition  names  are  essentially  the  program  name  used  to  generate  them  and  a 
number  (used  to  identify  different  verification  conditions  within  a program).  When 
the  system  is  expecting  the  user  to  input  a verification  condition  name,  after  the 
user  has  typed  a sufficient  number  of  characters  to  identify  the  program  name,  the 
rest  of  the  name  is  automatically  printed  out  to  the  point  where  a number  is 
needed.  The  user  can  then  type  the  verification  condition  number.  This 

eliminates  the  need  for  excessive  typing. 

• The  command  structure  is  tree-like  in  the  sense  that  some  commands  take 

subcommands,  which  in  turn  might  take  subcommands.  For  example,  the  PRINT 
command  is  used  to  print  programs,  verification  conditions,  and  verification  status. 

• At  any  point  in  the  command  structure,  as  mentioned  above,  the  user  may  type  a 
question  mark  (?)  and  the  list  of  the  next  alternatives  is  printed  out.  In  the 
example  above,  if  the  user  typed  a ? after  he  had  specified  that  he  wanted  to  print 
a verification  condition,  a list  of  the  verification  conditions  would  be  printed. 

• Also,  at  any  point  in  the  command  structure,  the  user  may  back  up  one  ' /el  by 

typing  a special  key.  He  may  then  reselect  from  the  menu  presented.  is  may 

be  repeated;  therefore,  after  typing  this  special  key  a sufficient  number  jf  times, 
the  user  will  be  back  at  the  top  of  the  command  structure. 

• The  space  bar  (tp)  serves  a special  purpose  at  the  beginning  of  a command  or 
subcommand.  If  typed,  the  system  suggestion  is  automatically  taken  and  the 
command  is  typed  out  instead  of  the  space.  Therefore,  if  the  user  always  wanted 
to  take  the  system’s  suggestion,  all  he  need  do  is  hit  the  space  bar. 

The  new  EXECUTIVE  greatly  increases  the  ease  of  using  the  verification  system.  It 
should  also  be  helpful  m bringing  new  users  up  to  competence  quickly. 
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V»er  Profile  Packttxe 

The  user  profile  package  was  motivated  by  two  basic  needs.  One  was  to  bring 
together,  in  a cohesive  package,  all  the  internal  flags  already  in  the  system.  These  flags 
were  knov.T  by  the  implementors,  but  this  knowledge  was  hard  (o  pass  on.  The  other 
motivation  was  to  have  certain  informat'cn  about  how  each  individual  user  wanted  the 
system  to  perform  for  him.  This  informiition  was  incorporated  into  the  system.  The  user 
profile  package  initiates  an  English  diaiOgue  with  the  user,  asking  him  the  appropriate 
questions.  After  the  user  respcns-'  is  interpreted,  the  internal  flags  are  set.  This 
package  should  be  very  helpful  for  a new  user;  since  he  can  enter  the  dialogue  at  any 
time,  he  can  change  the  system  as  he  progresses  in  using  the  verification  system. 


Theorem  Prover  Modificatiom 


Two  modifications  were  made  to  the  theorem  prover.  The  first  was  to  design  a new 
command  structure,  similiar  to  that  of  the  EXECUTIVE  During  this  process,  new  commands 
were  chosen  to  (1)  make  the  commands  reflect  the  operations  performed  and  (2)  combine 
into  one  command  operations  which  previously  had  to  be  done  in  a particular  sequence. 
See  [Yonke76]  for  a more  complete  description.  The  second  addition  was  motivated  by 
the  fact  that  the  user  had  to  remember  what  he  used  for  the  basis  of  the  proof  of  a 
particular  theorem.  The  theorem  prover  now  sends  information  to  the  EXECUTIVE,  whicli 
remembers  and  can  report  which  lemmas  and  rewrite  rules— the  basis  for  the  proof— were 
used  to  prove  a particular  theorem. 


This  work  or.  the  verification  system  has  made  it  much  more  I'sable,  for  both 
veteran  and  novice  users.  It  helps  the  user  by  both  gutding  him  through  the  verification 
process  and  keeping  track  of  information  which  was  formerly  the  user’s  reponsiblity. 
Even  though  it  is  possible  to  live  without  the  new  facilities,  we  insist  on  them  for  the 
analogous  reason  we  insist  on  high-level  programming  languages  rather  th.an  assembly 
codes.  Further  work  is  being  done  to  provide  new  facilities  to  alleviate  other  user 
burdens. 


EXTENSIBLE  VERIFICATION  CONDITION  GENERATOR 

The  only  component  of  a program  verification  system  which  is  entirely  new  to 
computer  technology  is  the  "verification  condition  generator”— that  portion  of  the  system 
which  determines  what  "theorems"  must  be  proved  in  order  to  establish  that  a program 
does  indeed  have  the  specified  properties.  The  XIVUS  system  is  intended  to  be  a tool  for 
verification  of  programs  written  in  several  different  languages.  At  the  same  time, 
research  is  under  way  into  the  best  way  to  formulate  and  describe  the  rules  for 
generating  verification  conditions  for  constructs  in  each  of  the  languages. 


The  current  verification  condition  generator  is  inadequate  for  these  purposes  in  that 
it  deals  with  only  one  language  (a  Pascal  subset),  and  modification  of  it  to  incorporate 
better  formulations  of  verification  conditions  is  quite  dif'icult.  These  and  several 
additional  considerations  led  to  the  design  and  implomentalion  of  a new  verification 
condition  generator  which: 
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• Can  be  used  with  several  different  programming  languages. 

• Can  t>e  modified  and  extended  easily. 

• Will  interface  with  an  editor  and  parser  to  provide  incremental  verification 
condition  generation  (reproving  a program  with  minor  changes  should  be  easy). 

• Accepts  an  enriched  "assertion  language"  used  by  the  programmer  to  indicate  the 
intended  properties  of  the  program. 


Both  the  new  and  old  veritrcation  condition  generators  are  based  on  the  ideas 
originated  by  King  and  Floyd,  reformalized  by  Hoare,  and  developed  by  many  others. 
However,  several  new  ideas  are  incorporated  in  the  new  one.  An  example  best  illustrates 
the  techniques.  An  inventory  program  which  removes  the  "current  order  quantity"  from 
the  "on  hand  quantity"  should  probably  have  the  property  that  afterwards  the  "on  hand 
quantity"  > 0.  If  there  is  an  assignment  statement  in  the  program  ONHAND  ♦-  ONHAND 
- CURRENTORDER,  then  a verification  condition  generator  that  "works  backwards"  will 
insist  that  the  user  prove  that  (ONHAND  - CURRENTORDER)  > 0.  This  "substitution  rule" 
(right-hand  side  of  the  assignment  for  the  left-hand  side  in  the  property  to  be  proved)  is 
actually  quite  dependent  on  the  forms  of  the  data  structures  involved.  For  example, 
ONHAND  might  actually  be  a file  access  parameterized  by  "part  number."  For  this 
reason,  the  new  verification  condition  generator  does  not  make  the  substitution  above;  it 
merely  indicates  that  one  is  to  be  made.  The  programming  language  designer  must 
provide  the  substitution  rules  to  be  used.  In  genera!,  the  new  generator  never  makes  a 
decision  that  is  either  ianguage-dependent  or  more  properly  made  by  another  component 
of  the  verification  system. 

To  continue  the  example,  the  programmer  might  precede  the  above  assignment  with 
a test;  |f  CURRENTORDER  > ONHAND  then  eoto  BACKORDER.  A verification  condition 
generator  which  "works  forward"  will  conclude  that  after  thi«;  statement  whatever  was 
true  before  the  if  still  holds.  In  addition,  -x  (CURRENTORDER  > ONHAND)  will  hold.  A 
verification  condition  that  could  be  generated  is 
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-V  (CURRENTORDER  > ONHAND) 
implies 

(ONHAND  - CURRENTORDER)  > 0 

(which  is  not  provable  since  it  is  not  in  fact  quite  true—there  is  an  inconsistency  between 
the  given  property  and  the  program). 

in  general,  for  any  path  through  a program  the  path  can  be  "marked"  and  a 
verification  condition  generated  that  the  predicate  at  the  mark  obtained  by  working 
forward  imp  .^s  that  obtained  by  working  backward.  The  new  technology  involved  is  to 
save  both  forward  and  backward  predicates  with  each  program  node,  enabling  incremental 
verification  and  enhancing  the  options  for  verification  condition  generation:  pure 

forward,  pure  backward,  or  a mixture  are  all  possible  within  the  new  system. 
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The  new  system  allows  for  different  languages  by  providing  an  extension 
mechanism;  ne-  syntactic  constructs  may  be  defined  for  any  particular  programming 
language  in  terms  of  old  ones.  Verification  conditions  and/or  Hoare  axioms  for  the 
construct  are  produced  from  the  definition  by  the  generator.  The  researcher  in 
verification  technology  or  programming  language  design  may  then  examine  and  modify 
these  rules,  which  are  automatically  invoked  when  the  syntactic  construct  is  used  in  a 
program. 

The  basis  for  this  technology— associating  the  predicates  with  the  nodos — was 
developed  in  part  by  Gerhart  [Gerhart75].  Although  the  technology  here  is  innovative, 
the  existence  of  the  tool  is  mcr«  important.  Future  extensions  to  the  verification 
condition  generator  include  enriching  the  syntactic  constructs  allowed  (to  parallel 
constructs),  enriching  the  semantics  which  can  be  conveyed  to  the  generator, 
encapsulating  the  substitution  rules  in  a language-independent  manner,  and  linking  the 
generator  into  the  XIVUS  system. 

NOTE:  The  inconsistency  can  be  removed  by  changing  the  given  property  to  "on 
hand  quantity  > 0." 


AtXiEBRAIC  APPROACH  TO  DATA  ABSTRACTIONS 

In  the  algebraic  approach  to  data  abstractions,  an  abstract  data  type  is  deflni-d  to 
be  a set  of  operations  on  a set  of  objects  and  a set  of  equations  relating  the  operations. 
Regarded  as  axioms,  the  equations  serve  as  a representation-indepe'ident  specification, 
on  which  applications  of  the  data  type  can  be  based  and  against  which  implementations 
can  be  compared.  An  implementation  of  a data  type  consists  of  a representation,  which 
indicates  how  the  abstract  objects  are  to  be  represented  in  terms  of  some  other  data 
type(s),  and  set  of  programs  for  the  operations  expressed  in  terms  of  the  representation. 
A correct  implementation  is  one  which  satisfies  the  axioms  of  the  specification. 

One  of  the  key  ideas  of  the  approach  taken  in  [Guttag7f.a]  is  to  express  both  the 
axioms  of  the  specification  and  the  programs  of  an  implementation  of  a data  type  as 
rewrite  rules.  With  a few  relatively  minor  restrictions  on  their  form,  these  rules  can 
be  compiled  or  interpreted  by  a relatively  simple  pattern-match  compiler  or  interpreter. 
Such  pattern-matching  systems  already  exist  in  symbolic  mathematical  systems  such  as 
Reduce,  Scratchpad,  and  Maesyma,  and  extensive  use  has  been  made  of  the  Reduce 
pattern-match  interpreter  in  the  work  reported  in  [Guttag76a]  and  [Gultag76b]. 

Expressing  both  axioms  and  programs  as  rewrite  rules  suggests  a duality  between 
specifications  ?.id  implementations  that  has  important  consequences  for  software  design, 
testing,  and  verification.  In  design  of  data  types,  the  duality  suggests  that  the  task  of 
initially  axiomatizing  a data  type  can  be  approached  as  a programming  task,  using 
expressions  (operator-operand  tree  structures)  as  a representation.  Using  this 
approach,  it  has  been  relatively  easy  to  axiomatize  familiar  data  types  such  as  stacks, 
queues,  binary  trees,  strings,  sets,  lists,  graphs,  and  files  [Guttag76b],  as  well  as  newly 
invented  types  such  as  "message  exchange." 
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Since  the  axioms  of  a data  type  can  be  compiled  into  running  programs,  this 
implementation  can  be  used  for  initial  testing  with  actual  or  symbolic  data,  pern^  ;>ng  the 
designer  to  test  to  a limited  extent  whether  his  specification  captures  the  properties 
intended.  One  can  also  test  high-level  algorithms  which  are  programmed  in  terms  of  the 
data  type  before  fixing  upon  an  actual  implementation  of  the  data  type.  Thus,  a true 
top-down  design  methodology  can  be  achieved  [Guttag7-'Sa]. 

Perhaps  the  most  important  consequences  of  the  axiom/program  duality  are  in 
verification.  By  using  both  axioms  and  programs  as  rewrite  rules  in  proofs,  the  proofs 
become  in  targe  part  very  straightforward  and  computational  in  nature.  In  this  rt:spect 
the  proof  method  is  very  similar  to  some  of  the  methods  of  [Boyer75]  for  verifying  Lisp 
programs.  Combination  of  the  axiomatic  approach  to  data  types  and  hierarchical 
development  of  software  results  in  a very  important  advantage  in  verification,  namely, 
factoring  proofs  into  the  same  hierarchical  structure  as  in  th^  programs  [Hoare72].  This 
'levels  of  abstraction*  approach  becomes  particularly  attractive  with  algebraic  axioms 
because  of  the  possibility  of  constructing  axiom  sets  which  are  in  an  important  sense 
complete  [Guttag75X 


/in  Ex'imple 

The  characteristics  of  algebraic  axiom  specifications  and  their  use  in  verification  are 
nicely  illustrated  by  the  example  of  a symbol  table  data  abstraction  and  its  implementation 
by  a stack  of  hash  tables.  This  example,  first  introduced  in  [Guttag/5],  provides  a 
collection  of  operations  for  maintaining  a symbol  table,  such  as  might  be  used  in  a compiler 
for  a block  structured  language.  The  informal  specifications  for  these  operations  include: 
(1)  upon  block  entry  one  can  redeclare  previously  used  symbols  (former  attributes  become 
inaccessible  until  exit  from  the  block);  and  (2)  upon  exit  from  a block,  attributes  declared  in 
the  block  become  inaccessible.  The  formal  specification  with  algebraic  axioms  defines  six 
operations  on  symbol  tables  with  nine  equations  which  relate  operations  to  each  other, 
e.g.,  LEAVEBL(XK(ENTERBLOCK(symtab))  - symtab.  The  axioms  define  the  behavior  of  the 
operations  precisely,  yet  do  not  prescribe  or  preclude  any  particular  implementation.  The 
operations  in  an  implementation  are  programmed  in  terms  of  operations  of  other  data 
abstractions,  for  which  there  are  axiomatic  specifications  which  can  be  used  in  carrying 
out  the  verification  that  the  symbol  table  axioms  are  satisfied.  The  symbol  table 
operations  can,  for  example,  be  implemented  by  a Stack  ot  Mappings,  the  Stack  being 
implemented  by  an  array/’ndex  pair  and  a Mapping  by  a particular  kind  of  hash  table  (an 
array  containing  lists  of  ioentifier/attribute  pairs).  The  verification  of  the  symbol  table 
axioms  then  involves  use  of  a set  of  axioms  for  Stack  operations,  e.g.,  POP(PUSH(stk,item)) 
■ stk,  and  a set  of  axioms  for  Mappings,  e.g., 

EVALMAP(DEFMAP(map,id,attr),idl)  - 

if  id»idl  then  attr  else  EVALMAP(map,idl). 

(The  form  of  this  axiom,  with  the  conditional  expression  and  recursive  occurrence  of 
EVALMAP  on  the  right-hand  side,  is  typical  of  the  form  used  in  algebraic  axiom 
specifications.)  The  particular  implementations  chosen  for  Stacks  and  Mappings  are 
verified  in  the  same  way,  using  basic  sets  of  axioms  for  arrays  and  lists,  it  is  important  to 
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note  that  the  verification  of  She  top  level  of  the  symbol  table  implementation  does  not 
require  Knowledge  of  the  particular  implementations  of  , Stacks  or  Mappings,  only  their 
axiomatic  specifications.  Thus  the  proof  of  the  entire  impi^ementation  factors  nicely  into 
levels. 


Seir.i-/lvitonuxtie  Verification  of  Data  Tyi>e  Implementationt 

To  carry  out  the  verification  of  data  type  implementations  using  the  algebraic 
approach,  a prototype  set  of  facilities  has  been  added  to  the  XIVUS  system.  Using  these 
facilities,  the  complete  implementation  of  the  symbol  table  data  type  using  a stack  of  ha'^h 
tables  has  in  fact  been  verified.  As  an  example  of  the  proof  process,  consider  the 
verification  of  the  top  level  implementation  by  a Stack  of  Mappings.  The  first  step  is  to 
direct  the  system  to  adopt  the  programs  of  data  type  symbol  table  and  the  axioms  of  data 
types  Stack  and  Mapping.  These  programs  and  axioms  would  all  be  it^  the  form  of  rewrite 
rules  which  the  user  had  just  entered  or  had  read  in  from  files.  The  command  for 
"adopting"  a sej  of  rules  is  separated  from  the  act  of  reading  them  in  so  that  several  sets 
of  rules  for  an  operator  can  coexist  within  the  system.  Assuming  that  the  symbol  table 
axioms  have  also  been  input  to  the  system,  the  user  then  directs  the  system  to  generate 
the  verification  conditions  for  the  data  type.  These  would  consist  of  the  symbol  table 
axioms  and  the  "equality  axioms"  for  the  symbol  table  equality  operator,  a!!  intei  preted  in 
terms  of  the  representation. 

The  user  can  then  attempt  to  prove  each  of  the  verification  conditions  using  CEVAL, 
a special  "conditional  evaluator"  which  has  been  developed  primarily  for  this  purpose 
[AR753,  [Guttag76a],  or  the  standard  simplifier/theorem  prover  of  the  system.  In  these 
proofs  the  rewrite  rules  from  the  Symbol  Table  programs  and  Stack  and  Mapping  axioms 
are  used  automatically,  without  further  direction  from  the  user.  In  some  rases,  completion 
of  a proof  requires  one  or  more  assumptions  to  be  made  about  the  representation  or  the 
Slack  or  Mapping  data  types.  Initially  these  assumptions  are  input  by  the  user  and  used 
as  needed  without  justification.  To  complete  the  verification  of  the  implementation,  it  is 
necessary  to  prove  these  assumptions,  or  a stronger  set  of  assumptions,  as  theorems 
(about  the  symbol  table  data  type  implementation  or  about  the  Stack  or  Mapping  data 
types).  The  verification  conditions  sufficient  to  establish  these  theorems  are  constructed 
using  the  domain/range  specifications  of  the  data  types,  in  accoioance  with  the  principle 
of  induction  on  the  number  of  applications  of  operations  of  the  data  type  [Hoare72]. 

Work  is  now  in  progress  on  extensions  to  the  basic  methodology  of  the  algebraic 
axiom  approach  to  permit  operations  with  side  effects  and  to  incorporate  error  handling 
systematically.  These  extensions  will  contribute  toward  integrating  the  data  abstraction 
components  of  the  XIVUS  system  with  the  existing  Pascal  verification  components  and 
future  components  for  verification  of  programs  in  other  languages. 
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T//£  IMPACr  OF  VERfflCATlON  ON  LANGUAGE  DESIGN 

In  addition  to  verifying  existing  programs,  written  mainly  in  Pascal,  we  have  been 
deeply  involved  this  year  in  the  design  of  two  new  programming  languages,  Euclid 
[Lampson76]  and  Alphard  [Wulf7&,  Shaw76bX  Both  of  the  language  designs  have  as  one 
of  their  important  goals  verifiability  of  the  resulting  programs.  Naturally,  additional  goals 
and  numerous  other  concerns  are  exerting  major  influences  on  these  languages. 
Nevertheless,  it  has  been  both  surprising  and  extremely  pleasing  to  observe  the  degi  ee  to 
which  these  concerns  have  reinforced  each  other.  We  deem  it  quite  appropriate  to 
provide  a short  glimpse  into  the  interactions,  starting  with  Euclid. 

The  Euclid  language,  drawing  heavily  on  Pasca'  and  deliberately  restricted  to  current 
Knowledge  of  programming  languages  and  compilers,  is  intended  for  the  expression  of 
system  programs  which  are  to  be  verified.  Soth  the  language  and  its  compiler  are  given 
part  of  the  task  of  producing  a correct  program  and  of  verifying  its  correctness.  For 
example,  although  global  variables  are  permitted,  they  must  be  explicitly  listed  when  used 
in  a procedure  or  a record.  This  explicit  listing  means  that  no  reader  of  a program  need 
do  computing  or  complex  searching  to  determine  the  global  variables.  One  class  of 
readers  in  particular,  fiuman  or  mechanical  verifiers,  has  this  information  readily  available 
for  use.  Furthermore,  the  language  is  able  to  guarantee  that  two  identifiers  in  the  same 
scope  can  never  refer  to  the  same  variable,  i.e.,  there  is  no  aliasing.  All  of  this  by 
deliberate  design  meshes  well  with  a new,  easily  explained  proof  rule  for  verifying 
procedure  definitions  and  calls.  The  proof  rule,  developed  for  Euclid  from  several  existing 
proof  lules,  captures  exactly  the  full  Euclid  procedure  definition  and  call  mechanism  and 
also  removes  restrictions  and  Known  problems  with  other  proof  rules.  In  a very  real 
sense,  the  Euclid  design  is  one  of  adding  restrictions  and  the  enforcing  mechanisms  to 
meet  a desired  level  of  understandability  and  verification  capability. 

The  use  and  verification  of  pointers  in  Euclid  is  made  easier  than  in  other  languages 
by  allowing  each  dynamic  variable  to  be  assigned  to  a language  construct,  the  collection, 
and  guaranteeing  that  two  pointers  into  different  collections  can  never  refer  to  the  same 
variable.  Thus  assertions  need  not  be  invented  and  verified  to  obtain  this  guarantee; 
instead  it  is  all  part  of  the  language. 

When  possible,  the  above  guarantees  are  provided  by  extensive  compile-time 
checks.  If  the  compiler  is  unable'  to  complete  a check,  it  generates  legality  assertions  for 
the  verifier  to  establish.  Verification  concepts  are  thereby  used  to  complement  other 
mechanisms. 


The  Alphard  langu.-'ge  is  a new  language  design  rather  than  one  starting  from  an 
existing  language.  The  effort  focuses  simultaneously  on  issues  of  programming  structure 
(methodology)  and  verification.  The  abstraction  mechanism  of  Alphard,  the  form, 
encapsulates  a set  of  related  function  definitions  and  associated  data  descriptions,  allowing 
a programmer  to  reveal  the  behavior  of  an  abstraction  to  other  users  while  hiding 
information  and  protecting  details  of  the  concrete  implementation. 

This  explicit  distinction  between  the  abstract  behavior  of  a data  abstraction  and  the 
concrete  program  that  happens  to  implement  that  behavior  provides  an  ideal  setting  in 
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which  to  apply  Hoare’s  techniques  for  proving  the  correctness  of  data  representations 
[Hoare72].  In  the  Alphard  adaptation  one  shows  that  the  concrete  representation  is 
adequate  to  represent  the  abstract  objects,  that  it  is  initialized  properly,  and  that  each 
operator  provided  on  the  abstract  objects  both  preserves  the  integrity  of  the 
representation  and  does  what  it  is  claimed  to  do  (in  terms  of  both  the  abstract  behavior 
and  the  concrete  procedure  that  actually  implements  the  operator). 

The  verification  technioue  and  the  methodology  decisions  both  require  providing 
specifications  of  the  abstract  objects  and  the  related  operations.  They  also  need 
conditions  describing  the  concrete  objects  and  operations,  invariants  holding  over  all 
operations,  and  a representation  function  giving  the  relation  between  concrete  and 
abstract  objects.  All  of  this  information,  made  an  integral  part  of  a form  definition,  was 
originally  included  for  verification  reasons.  Its  presence,  however,  has  directed  attention 
toward  things  which,  on  methodological  grounds,  ought  to  be  of  concern.  The  verification 
technique  exposed  the  need  for  certain  language  features,  which  at  besj  were  viewed  as 
conveniences  and  at  worst  would  have  been  missed  completely  on  the  basis  of 
methodological  or  language  considerations  alone. 

Methodology  concerns  have  also  benefited  verification.  The  entire  form  concept, 
for  example,  was  introduced  for  methodological  reasons.  It  is  this  factorization  and 
isolation,  however,  which  appears  to  make  either  hand  or  mechanical  verification  feasible. 
Similarly  the  notion  of  generators,  which  permits  hiding  certain  details  of  iteration,  was 
introduced  on  methodological  grounds,  but  is  also  simplifying  the  verification  of  many 
loops.  Loop  control  using  generators  is  implicit  rather  than  explicit,  and  therefore  a single 
verification  of  that  loop  control  suffices  for  all  of  its  invocations. 

An  important  part  of  language  design  is  knowing  what  should  be  left  out.  During 
the  Alphard  design,  constructs  were  repeatedly  proposed  which  '■■the.'  gave  difficulty  in 
formulating  the  needed  proof  rules  or  which  looked  suspect  on  methodological  grounds. 
Usually  such  a problem  signalled  an  unforeseen  problem  in  the  other  domain.  For 
example,  an  early  version  of  the  iteration  statement  was  much  more  elaborate  than  the 
one  currently  adopted.  Nevertheless,  it  seemed  plausible  on  methodological  grounds.  Its 
verification,  however,  was  a horror  te  behold.  Subsequently  it  became  apparent  that  the 
complexity  of  its  verification  was  symptomatic  of  a difficulty  which  any  programmer  would 
have  in  attempting  to  understand  the  statement  or  its  use. 

Numerous  example  forms,  and  programs  using  these  forms,  have  been  designed  and 
verified  [Wulf76,  Shaw76b,  London76,  Shaw7Ga].  The  proofs  are  modular,  reflecting  the 
structure  of  the  programs.  In  addition,  the  lengths  of  the  proofs  are  within  reasonable 
limits  and  indeed  quite  encouraging.  Most  importantly,  when  modifications  have  been 
made  to  a program,  corresponding  modifications  needed  in  the  proof  have  been  nearly 
always  easy  to  identify  and  to  complete,  without  the  need  to  redo  the  entire  proof.  If  the 
implementation  of  an  abstraction  is  changed,  but  not  the  specifications,  then  all  programs 
using  the  abstraction  and  all  verifications  of  those  uses  are  also  unchanged. 

Even  if  we  nevei"  verify  another  program  (and  no  one  even  remotely  believes  that 
to  be  the  case),  already  the  impact  of  verification  on  language  design  and  the  expression 
of  quality  programs  is  significant  and  worthwhile.  In  fact,  one  of  our  colleagues. 
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responding  to  an  early  revision  of  one  of  these  languages,  noted  that  it  is  "thrilling  to  see 
verification  finally  interacting  with  language  design." 
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INTRODUCTION 

PRIM  is  an  interactive  microprogrammable  environment  used  for  creating  emulators 
of  existing  cr  newly  specified  computers  with  major  emphasis  on  providing  programming 
debugging  tools;  it  is  available  via  remote  terminals  through  the  ARPANET.  PRIM  provides 
editors,  compilers,  and  debuggers  for  creating  errtulators  as  well  as  an  environment  for 
providing  target  systems  with  debuggers  and  configurers  that  can  be  operated  by  the 
user  in  the  familiar  language  of  the  original  system.  The  emulated  machine  generally 
provides  better  user  debugging  facilities  and  greater  flexibility  in  system  configuration 
than  the  original  machine,  while  producing  bit-to-bit  compatible  results  on  all  levels  of 
execution.  PRIM  is  an  attempt  to  generalize  a solution  to  the  problem  of  software 
development  by  means  of  emulation  tools;  it  is  a unique  and  powerful  facility  for  improving 
software  development  within  the  DoD  user  community. 

The  goals  of  the  PRIM  project  are  to  facilitate  more  efficient  programming  by 
providing  and  demonstrating  integrated  emulation-based  tools  that  can  give  the  user  the 
ability  to  create,  debug,  and  execute  programs  for  target  machines  in  an  interactive 
(time-shared)  environment  richer  in  necessary  user  facilities  than  the  original.  These 
tools  are  integrated  into  the  National  Software  Works  (NSW)  system  (see  Section  7), 
tr'I'.ing  them  available  on  the  ARPANET.  PRIM  is  therefore  a service  facility,  providing 
unique  tools  to  NSW  programmers,  as  well  as  an  experimental  computer  environment  for 
the  researcher.  The  major  implementations  are  the  PRIM  environment,  a tool  for  emulator 
tool  builders,  and  two  sample  emulations,  a UYK-20  tool  and  a U1050  tool. 

The  use  of  emulations  (i.e.,  simulations)  of  unavailable  computer  systems  as  an  aid  in 
programming  large  systems  is  certainly  not  novel.  The  uniqueness  of  PRIM  is  to  provide 
an  integrated  set  of  user  tools,  available  via  remote  terminals,  utilizing  a well  supported 
general-purpose  multiaccessed  computer  system  (TENEX)  and  near  real-time  emulations, 
rich  in  debugging  aids,  for  software  development.  Like  NSW,  the  major  aim  of  the  PRIM 
project  is  to  permit  the  military  community  easy  access  to  the  most  recent  computer 
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technology,  allowing  the  use  of  an  existing  operating  system,  editors,  compilers,  and  other 
programs  for  creating  and  debugging  new  software.  In  addition,  PRIM  is  demonstrating  the 
ease  of  irjtroducing  some  types  of  new  tools  into  NSW  by  emulating  the  computer  system 
rather  than  implementing  hardware  and  software  compatible  with  the  protocols  of  th^  NSW 
operating  system  and  the  ARPANET. 

The  major  project  effort  for  this  reporting  period  is  the  design  and  implementation 
of  a PRIM  system  tailored  to  the  needs  of  military  programmer  while  enhancing  the 
emulator-writing  capabilities  for  additional  tools  operable  within  the  PRIM  facility.  This 
new  effort  utilizes  the  PRIM  facility  completed  in  1975.  (A  detailed  description  is  found  in 
the  PRIM  UsePs  Manual  and  need  not  be  repeated  here.)  The  tasks  being  completed  for 
this  reporting  period  are  as  follows: 

• New  TENEX  MLP-900  Driver 

• PRIM  Exec 

• PRIM  Debugger 

• PRIM  Tool 

• UYK-20  Tool 

• U1050  Tool 


THE  PRIM  FACILITY 

The  PRIM  system  was  developed  at  ISI  as  a subsystem  of  TENEX.  PRIM  consists  of 
an  MLP-900  microprogrammable  processor  and  appropriate  software  to  drive  the 
MLP-900,  to  support  MLP-900  microprogramming,  and  to  provide  an  environment  in  which 
users  create,  manipulate,  and  interact  with  their  emulators  and/or  emulated  systems. 


Hardware 

prim’s  hardware  system  is  based  on  two  processors:  the  shared  use  of  a Digital 
Equipment  Corporation’s  PDP-10  with  other  network  users  and  the  STANDARD  Computer 
Corporation’s  MLP-900  prototype  processor.  The  PDP-10  and  MLP-900  share  memory  as 
dual  processors;  the  MLP-900  is  also  a device  on  the  PDP-10  I/O  bus.  The  PDP-10, 
connected  to  the  ARPANET,  runs  under  TENEX  with  a paged  virtual  memory.  Its  processor 
contains  256K  words  of  36-bit  memory.  The  I/O  operations  performed  by  TENEX  include 
file,  terminal,  and  network  handling,  swapping,  and  all  other  accesses  to  peripheral  devices. 

The  MLP-900  is  a fast,  powerful  vertical-word  microprogrammed  computer  that  has 
been  tailored  to  interface  the  TENEX  system.  It  contains  4K  36-bit  words  of  control 
memory,  80-nanosecond  cycle  time,  and  runs  asynchronously  with  a 4 MHz  clock.  A major 
modification  of  the  MLP-900  has  been  the  introduction  of  a supervisor  state  which  allows 
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th«  processor  to  be  shared  with  full  protection  between  users.  Prior  to  this  project,  little 
had  been  done  toward  making  the  multitude  of  available  microprogrammed  processors 
potentiaily  sharable  resources.  This  initial  experiment  goes  a long  way  toward  making 
microprogrammed  processors  widely  and  inexpensively  available.  The  hardware 
environment  was  completed  in  1974. 


Softuare 

The  principal  items  of  PRIM  software  are  the  General  Purpose  Microprogramming 
Language  (GPM)  compiler,  the  MLP-900  microprogram  supervisor  (microvisor)  and  the 
MLP-EXEC.  The  remaining  software  --  TENEX  MLP-900  Driver,  PRIM  Exec  and  Debugger 
(PRIM  Tool),  the  UYK-20  emulator,  and  the  U1050  emulator  --  was  implemented  during  this 
reporting  period. 

GPM  and  the  GPM  Compiler.  GPM  is  a high-level  machine-oriented  language, 
designed  explicitly  for  writing  programs  for  the  MLP-900.  As  a high-level  language,  GPM 
offers  a block  structure  and  statement  syntax  similar  to  PL/1  or  ALGOL.  The  compiler  is 
capable  of  producing  multi-instruction  code  per  statement  as  well  as  statements  producing 
exactly  one  MLP-900  instruction  per  statement.  The  GPM  compiler  was  essentially 
completed  in  early  1974;  for  a more  detailed  account  of  its  development  the  reader  should 
consult  the  PRIM  User*s  Manual. 

MLP-900  Microvisor.  The  MLP-900  microprogram  supervisor  (microvisor)  is  a small, 
fully  protected  resident  system  that  controls  the  MLP-900  and  its  communication  with  the 
PDP-10.  It  loads  and  unloads  the  user’s  MLP-900  context  upon  command  from  the 
PDP-10,  supports  paging  of  the  user  target  program,  protects  main  memory  and  the  rest 
of  the  PDP-10  system  from  emulator  errors,  and  provides  the  emulator  with  a few  other 
services.  The  microvisor  interacts  only  with  the  user  microcode  and  the  TENEX  MLP 
driver 


The  TENEX  MLP-900  Driver.  Access  to  the  MLP-900  from  a TENEX  process  is 
accomplished  via  the  MLP  driver  in  TENEX.  The  driver  is  responsible  for  initializing  the 
MLP-500  microcode,  controlling  and  swapping  users,  and  passing  along  all  the  I/O  requests. 
The  driver  is  an  extension  of  the  microvisor;  all  communication  with  the  MLP-900  goes 
through  the  driver,  while  communication  with  the  driver  occurs  througii  the  normal  I/O 
JSYS’s. 

To  improve  the  security  and  efficiency  of  operation,  the  current  version  of  the 
driver  has  been  incorporated  into  the  TENEX  monitor.  The  new  TENEX  MLP-900  driver 
will  appear  functionally  the  same  to  PRIM  users  as  the  original  driver  (written  as  a user 
program)  with  improvements  in  responding  to  page  faults,  swapping,  and  I/O  requests. 
The  MLP-900  is  an  I/O  device  to  TENEX  and  uses  existing  system  calls  for  communication. 
The  security  of  the  system  was  improved  by  denying  the  PRIM  users  the  ability  to  write 
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and  load  their  own  tnic">visor.  This  capability  is  restricted  to  maintenance  mode  and  only 
used  by  ISI  personnel. 

PRIM  Exec.  The  PRIM  Exec  has  replaced  MlP-EXEC  for  the  emulator  user. 
(MLP-EXEC,  described  in  the  PRIM  Unr*s  Manual,  served  as  the  vehicle  for  creating  and 
checking  out  MLP  emulations  prior  to  the  development  of  the  PRIM  Exec  and  is  replaced  by 
the  PRIM  Exec.)  The  PRIM  Exec  provides  the  environment  in  TENEX  needed  to  support  each 
of  the  PRIM  MLP-900  emulators,  together  with  a command  language  allowing  the  user  of  a 
particular  (emulated)  computer  to  access  that  environment  with  the  already  familiar 
vocabulary  of  that  computer. 

The  emulator  support  consists  of  the  module  responsible  for  controlling  (emulated) 
execution,  plus  a server  responsible  for  satisfying  the  emulator’s  I/O  requests.  This  I/O 
server  offers  the  emulator  a full  range  of  I/O  operations,  including  "magnetic  tape"  and 
"disk"  operations  (actually  performed  on  structured  TENEX  disk  files). 

A command  language  interpreter  in  the  PRIM  Exec  provides  a uniform  terminal 
interface  modelled  after  the  TENEX  Exec,  but  with  commands  oriented  toward  the 
needs— and  vocabulary--of  the  programmer  familiar  primarily  with  the  computer  being 
emulated;  additional  facilities  are  provided  the  emulator-writer  for  the  development  and 
checkout  of  a new  emulator  for  the  PRIM  system.  (The  tailoring  of  the  PRIM  Exec,  and  also 
the  PRIM  debugger,  to  the  details  of  a particular  emulated  machine,  including  its 
terminology,  is  accomplished  through  a set  of  machine-specific  tables  that  accompany  each 
emulator.) 

The  majority  of  the  commands  concern  the  building  (and  interrogating)  of  the 
emulated  machine’s  environment,  e.g.,  installing  devices  on  the  machine,  mounting  TENEX 
files  on  those  devices,  and  modifying  the  size  of  memory.  In  addition,  there  are  commands 
that  allow  a complete  checkpoint  and  subsequent  restoration  of  the  user’s  state  and  the 
generation  of  a transcript  of  all  or  part  of  a PRIM  session. 

PRIM  Debugger.  The  TRIM  debugger  is  a table-driven  interactive  symbolic 
debugger  that  permits  a user  of  the  PRIM  system  to  debug  target-machine  programs  in 
terms  of  symbols  defined  for  the  target  machine,  using  the  data  representation  and 
instruction  formats  of  that  machine.  The  debugger  also  provides  symbolic  access  to  the 
MLP  context;  it  uses  a command  language  with  feedback  and  help  available  if  needed. 

Some  of  the  abilities  provided  by  the  PRIM  Debuggei  are 

1.  To  evaluate  expressions  of  arbitrary  complexity  using  the  target 
machine’s  arithmetic  and  recognizing  the  target  machine’s  symbols. 

2.  To  display  and  modify  the  contents  of  lists  and  ranges  of  target-machine 
location,  including  some  control  panel  functions. 
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3.  To  set  and  clear  any  number  of  read,  write,  and  execute  program  breaks 
(or  any  combination  thereof)  whenever  in  the  target  machine  they  are 
appropriate  (breakpoints  are  marked  in  metabits  in  target  memory). 


5. 


To  display  a history  of  the  most  recent  target  program  jumps  and  transfer 
control  to  designated  addresses. 

To  assemble  symbolic  target  machine  instructions  on  input  and 
disassemble  them  on  output,  including  symbolic  expressions  as  addresses.’*‘ 


The  tables  that  supply  machine-specific  information  to  the  debugger  are  supplied  by 
the  emulator  developer.  Among  the  information  contained  are 

1.  Descriptions  of  the  properties  of  various  target-machine  and  MLP  address 
spaces. 

2.  Symbol  tables  for  all  target-machine  symbols  and  appropriate  emulator 
symbols. 

3.  An  instruction  format  description,  including  symbolic  op  codes. 

4.  Routines  to  convert  from  the  internal  data  representation  of  the  debugger 
to  the  data  representation  of  the  target  machine  and  vice  versa. 

5.  Routines  to  perform  arithmetic  and  logical  operations  according  to  the 
conventions  of  the  target  machine. 


DESCRIPTION  OF  PRIM  TOOL 

As  a tool,  PRIM  is  the  hardware  and  software  mentioned  above,  plus  a new 
user’s  manual  directed  towards  future  emulator  implementors;  the  latter  is  the  o:  ly 
component  lacking  (completion  is  scheduled  for  FY77).  In  general,  we  are  striving  for  a 
complete,  exact  emulation  of  the  target  machine,  including  not  just  instructions  and 
registers,  but  also  clocks,  interrupts,  machine  states,  memory  protection  and  relocation, 
and  nearly-real  I/O.  Complete  instruction  sets,  functionally  identical  to  the  emulated  CPU, 
are  required  to  produce  bit-compatible  results  in  the  working  registers.  The  actual 
implementation  of  machine  instructions  is  transparent  to  the  user;  the  emulation  need  be 
"correct”  omy  at  those  windows  in  the  emulated  cycle  where  interrupts  may  logically 
occur. 
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Also,  we  are  striving  for  a better  target  system  for  debugging  new  programs  even 
at  the  expense  of  slower  execution  time.  To  achieve  this  goal,  PRIM  emulators  are  limited 
to  32-bit  computers,  where  th''  extra  bits  are  used  as  meta-bits  for  the  conditional  breaks. 
Emu.ated  timing  information  is  provided  for  instruction  executors  as  memory  references 
and  I/O.  Jump  history  queues  are  provided  for  several  of  the  most  recent  target  system 
jumps.  A number  of  parameters  are  provided  to  allow  users  to  easily  configure  and  save 
individual  compute*-  systems  (I/O  devices,  memory  size,  speed  of  CPU,  etc.).  The  major 
attributes  for  PRIM-based  tools  is  in  its  flexibility  and  in  that  the  debugging  environment  is 
external  to  the  target  machine  •-.d  does  not  interfere  or  change  the  run-time  properties  of 
the  target  programs. 

/lN/UYK-20  EMULATOR 

We  have  completed  a ’RIM-based  emulation  of  the  AN/UYK-20  which  provides  a 
complete  and  accurate  AN/UYK-20  processor,  as  detailed  below;  included  in  the  emulation 
are  CPU  instruction  execution,  channel  instruction  execution  and  data  transfer,  clocks, 
interrupts,  control  panel  switches,  and  an  assortment  of  asynchronous  I/O  devices. 

ImtrvLCtion  Execution 

The  complete  basic  instruction  set  is  implemented;  the  optional  instructions 
(MathPack)  are  not  included  in  the  initial  release  but  will  be  available  in  FY77.  Where  the 
AN/UYK-20  specification  states  a restriction  on  the  use  of  an  instruction,  but  does  not 
specify  the  consequences  of  violating  that  restriction  (e.g.,  requiring  even  registers  in 
"double"  instructions),  the  emulator  halts  and  reports  a program  anomaly  when  such  a 
violation  occurs.  Indirect  addressing  under  the  control  of  Status  Register  2 and  relat” 
addressing  via  page  registers  are  included. 


Memory 

Both  main  memory  and  NDRO  are  implemented.  Main  memory  size  may  be  altered  in 
8K  increments;  the  available  memory  is  assumed  to  be  contiguously  addressable  from  zero. 
The  memory  is  a single-port  memory  (but  adding  DMA  as  part  of  a device  requiring  it  is 
straightforward). 


IOC  EXECUTION 

I/O  Controller  (IOC)  command  and  chaining  execution  are  implemented,  together  with 
byte,  word,  and  double-word  data  and  function  transfers.  All  sixteen  channels,  and  their 
control  memory,  are  available.  All  data  t<-ansfers  (between  emulated  channels  and 


1 


ifciifiaaijMMtYPrTr^^  


F- 

I 1 PROGRAMMING  RlTSEARCH  INSTRUMENT  19 

! 

I I 

emulated  devices)  are  byte-parallel,  using  the  natural  byte  size  of  the  device.  Data  (and 
function)  transfers  in  all  cases  are  driven  by  the  device,  at  the  device’s  rate,  ignoring  any 
programmed  modulation  rate. 

This  implementation  is  correct  for  parallel  and  NTDS  channels.  For  asynchronous 
communication  channels,  the  only  visible  effect  on  programs  is  that  the  data  transfers  run 
"correctly**  regardless  of  the  serial  information  provided  to  the  channel.  For  synchronous 
communication  channels,  an  additional  problem  arises  when  there  is,  in  fact,  a ^u^e  bit 
stream;  for  such  a device,  the  emulation  must  do  bit-at-a-time  transfers,  using  the  serial 
info  to  reassemble  the  **bytes**. 

Clocks  and  Timing 

Both  real-time  and  monitor  clock  registers  are  implemented,  with  a user-specifiable 
modulation  rate  (the  default  is  the  internal  rate,  which  is  one  millisecond).  AN/UYK-20 
time  is  counted  in  a 50-nanosecond  internal  timer;  no  relationship  is  specified  between 
real  (MLP)  time  and  AN/UYK-20  time.  Emulated  instruction  timing  (both  CPU  and  IOC)  is 
counted  according  to  the  AN/UYK-20  specification. 

Interrupts 

The  complete  interrupt  facility  is  implemented,  and  all  interrupts  (except  power 
fault)  are  generated  when  appropriate.  Power  fault  (and  any  other  interrupt)  can  be 
forced  by  the  user  by  setting  the  associated  flag  via  the  debugger. 

Console  Suitches 

Various  control  panel  switches  are  implemented  as  cells  which  can  be  manipulated 
by  the  user  (using  the  debugger).  Normal  toggles  are  set  by  the  user  and  sensed  by  the 
emulator;  return-to-neutral  toggles  are  set  by  the  user,  then  cleared  by  the  emulator  after 
it  has  senseo  the  setting.  The  implemented  switches  are  Bootstrap,  Load/Stop,  Program 
Stop,  and  Clock  Disable.  There  are  .no  indicators  as  such;  all  the  registers  and  state 
information  are  'Accessible  through  the  debugger. 

I/O  Devices 

All  emulated  I/O  devices  run  asynchronously  with  respect  to  the  AN/UYK-20 
processor  (CPU  and  IOC),  scheduling  themselves  for  MLP  service  in  terms  of  the  internal 
(50-nanosecond)  timer.  Device  timing  is  based  upon  a single  parameter  which  expresses 
the  time  required  for  one  basic  operation,  typically  the  interbyte  time  interval.  Scheduling 
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for  all  operations  is  based  upon  fixed  rebtionships  with  the  timing  parameter.  The 
parameter  for  each  device  can  be  set  by  the  user,  with  the  default  giving  the  actual  device 
speed. 

The  initial  complement  of  devices,  required  by  the  Level  II  software,  is  as  follows: 

• Univac  1532  I/O  console. 

• Cipher  Mark  I magr^etic  tape  system.  Reads  and  writes  emulated  tape 
files  within  the  TENEX  disk  system;  a utility  for  converting  between  real 
magnetic  tapes  and  these  emulated  tapes  is  available. 

• Oocumation  card  reader.  Capable  of  reading  either  TENEX  ASCII  text  files 
or  card  binary  files. 

• Versatec  matrix  printer. 

Channel  and  Device  Configuration 

Installation  is  done  on  a channel -by -channel  basis.  Each  installed  channel  may  have 
any  implemented  device  installed;  the  emulation  system  has  no  restrictions  regarding 
channel  groups,  and  does  not  enforce  any  such  restrictions.  Installing  a device  implicitly 
specifies  the  type  of  channel;  one  may  not  mount  a device  on  the  wrong  type  of  channel. 
Mounting  is  done  on  installed  devices  by  associating  TENEX  file(s)  with  the  device.  For 
devices  which  are  actually  multidevice  controllers,  mounting  is  done  separately  on  each 
unit.  In  general,  a single  TENEX  file  is  mounted  on  each  device;  in  the  case  of  emulated 
terminals,  however,  separate  input  and  output  files  are  needed  when  disk  files  are  to  be 
used.  Translation  of  data,  where  applicable,  is  specified  at  this  time.  The  speed  (transfer 
rate)  of  a device  can  be  specified  at  any  time;  the  default  is  the  actual  device  speed. 

UIOSO  TOOL 

We  have  completed  a PRIM-based  emulation  of  the  U1050  which  provides  a complete 
and  accurate  processor  as  detailed  below;  included  in  the  emulation  are  CPU  instruction 
execution,  I/O  instruction  and  data  transfer,  clocks,  interrupts,  control  panel  switches,  .and 
an  assortment  of  asynchronous  I/O  devices. 


Instruction  Execution 

The  complete  instruction  set  is  implemented.  As  with  the  AN/UYK-20,  where  the 
U1050  specification  states  a restriction  on  the  use  of  an  instruction  but  does  not  specify 
the  consequences  of  violating  that  restriction,  the  emulator  halts  and  reports  a program 
anomaly  when  such  a violation  occurs. 
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Memory 

Main  memory  size  may  be  altered  in  8K-byte  increments;  the  available  memory  is 
assumed  to  be  contiguously  addressable  from  zero. 


Clockt  and  Timing 

U1050  time  is  counted  in  a bG-nanosecond  internal  timer;  no  relationship  is  specified 
between  real  (MLP)  time  and  U1050  time.  Emulated  instruction  and  controller  timing  is 
counted  according  to  the  U1050  specification. 


Interrupti 

The  complete  interrupt  facility  is  implemented,  and  all  interrupts  (except  internal 
parity  errors)  are  generated  when  appropriate.  Any  interrupt  can  be  forced  by  the  user 
by  setting  the  associated  flag  via  the  debugger. 


Conao/e  StoUehet 

Various  control  panel  switches  are  implemented  as  cells  (hat  can  be  manipulated  via 
the  debugger.  Normal  toggles  are  set  by  the  user  and  sensed  by  the  emulator; 
momentary  switches  or  toggles  are  set  by  the  user,  then  cleared  by  the  emulator  after  it 
has  sensed  the  setting.  The  implemented  switches  are  Clear,  Start,  Continue,  Card-load, 
Tape-load,  Operator  request,  and  three  sense  switches.  There  are  no  indicators  as  such, 
since  other  control  functions  are  available  through  the  debugger. 


I/O  Devices 

All  I/O  devices  are  implemented  except  for  high-speed  communications.  All  channels 
(except  4 and  5)  are  available.  All  data  transfers  (between  emulated  channels  and 
emulated  devices)  are  byte-parallel,  using  the  natural  byte  size  of  the  device.  Data 
transfers  in  all  cases  are  driven  by  the  device,  at  the  device’s  rate. 

All  emulated  devices  run  asynchronously  with  respect  to  the  U1050  processor, 
scheduling  themselves  for  MLP  service  in  terms  of  the  internal  (50-nanosecond)  timer. 
Device  timing  is  either  fixed  in  the  emulation  or  is  based  upon  a single  parameter  that 
expresses  the  time  required  for  one  basic  operation,  typically  the  interbyte  interval. 
Scheduling  for  all  operation  is  based  on  fixed  relationships  with  the  timing  parameter. 
The  parameter  for  each  device  can  be  set  by  the  user,  with  the  default  giving  the  actual 
device  speed. 
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ThC'  implemented  I/O  devices  consist  of  a printer,  car'J  reader,  card  punch, 
low-speef  communications  (up  to  15  units),  mass  storage  (one  disK  unit),  and  one 
read/writo  tape  unit. 


Device  Configuration 

Installation  is  done  on  a channel-by-channel  basis.  As  each  UI050  channel  is 
committed  to  a particular  type  of  device,  care  must  be  exercised  that  each  device  is 
installed  on  its  proper  channel. 


coNCwsmss 


By  October  1976  the  PRIM  project  will  have  realized  all  its  major  goals:  to  provide  a 
rich  microprogramming  environment  for  computer  scientists,  provide  programming  tools 
under  NSW  to  the  military  community,  and  make  the  technology  available  to  the  DoD 
community.  (As  mentioned  above,  the  necessary  documentation  will  be  completed  during 
FY77.)  The  PRIM  facility  will  remain  at  l$l  and  continue  to  support  the  efforts  of  NSW  and 
SDL  in  providing  integrated  ccnputer  tools  for  programmers  and  system  designers.  PRIM 
personnel  will  continue  to  support  these  users  by  completing  the  PRIM  environment 
(adding  configurer),  completing  the  user  documentation,  providing  user  guidance,  and 
improving  the  capabilities  of  the  existing  tools.  Two  planned  implementations  are  a dual 
UYK-20  emulation  and  a controller  for  real-time  inputs. 


When  these  tools  are  completed,  the  PRIM  project  will  have  successfully  completed 
the  PRIM  tool  and  the  UYK-20  and  U1050  tools.  We  are  optimistic  about  user  acceptance 
of  these  tools  and  the  whole  PRIM  environment.  The  PRIM  architecture  (characterized  by 
the  dual  processors,  one  of  which  is  multiaccessed,  available  via  remote  terminals,  and 
provides  a well  supported  general-purpose  programming  environment  rich  in  programming 
tools  and  the  other  of  which  is  a fast  microprogrammable  CPU)  is  the  correct  approach  to 
providing  emulation-based  programming  tools.  The  military  community  has  recently  shown 
interest  in  using  emulation-based  tools  to  implement  and  develop  large  software  systems. 
The  existence  and  general  availability  of  PRIM  should  provide  incentives  for  the 
development  of  additional  PRIM-like  systems  for  general  use. 
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INTRODUCTION 

Only  modest  gains  in  programning  productivity  have  bean  produced  in  25  years  of 
software  research,  but  the  groundwork  has  been  laid  for  major  advances  through 
rationalization  and  automated  aids.  This  groundwork  rests  on  two  critical  ideas;  that 
specification  must  be  separated  from  implementation,  and  that  the  separation  between 
these  two  processes  should  be  a formal  operational  abstract  (i.a.,  vary  high  level)  program 
rather  than  a nonoperational  requirements  specification.  Structured  programming 
represents  the  first  results  of  combining  these  ideas.  It  is  a special  case  of  a more 
general  two-phase  process,  called  Abstract  Programming,  in  which  an  informs'  and 
imprecise  specification  is  transformed  into  a formal  abstract  operational  program,  which  is 
then  transformed  into  a concrete  (i.e.,  detailed  low-level)  program  by  optimisation. 
Abstract  programming  thus  consists  of  a specification  phase  and  an  implementation 
(optimization)  phase  which  share  a formal  abstract  operational  program  as  their  common 
interface. 

The  concept  of  abstract  programming  is  completed  by  adding  the  feedback  loops 
required  by  testing,  maintenance,  and  tuning.  In  conventional  programming,  where  no 
abstract  program  exists,  these  feedback  loops  all  operate  on  the  optimized  concrete 
program.  On  the  other  hand,  in  abstract  programming,  if  an  effective  method  can  be 
found  for  guaranteeing  the  validity  of  an  implementation  (that  is,  the  functional  equivalence 
of  the  abstract  and  concrete  programs),  then  the  validation  process  can  be  shifted  to  the 
specification  phase  to  show  equivalence  between  the  user  requirements  and  the  abstract 
program.  Thus,  validation  could,  and  should,  occur  before  any  implementation. 
Furthermore,  if  the  implementation  process  could  be  made  inexpensive  through  computer 
aids,  then  maintenance  could  be  performed  by  modifying  the  specification  and 
reimplementing  it  rather  than  directly  modifying  the  optimized  concrete  program,  as  is 
current  practice.  The  importance  of  such  an  advance  can  be  recognized  when  one 
realizes  that  optimization  is  the  process  of  maximally  spreading  information  (to  remove 
redundant  processing),  and  that  modification  requires  information  localization.  Thus,  the 
two  processes  are  diametrically  opposed;  this  fact  explains  much  of  the  current  problem 
with  modifying  and  maintaining  existing  programs.  The  second  major  cause  of  this  dilemma 
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PROJECT  COALS 

The  Specification  Acquisition  project  has  therefore  adopted  as  its  goal  the 
development  of  a system  that  aids  system  specifiers  in  converting  their  informal 
specificiitions  into  a precise  operational  abstract  program.  To  produce  such  a system  we 
needed  both  an  understanding  of  the  structure  and  content  of  such  informal  specifications 
and  a theory  of  how  they  could  be  formalized.  We  therefore  first  undertook  an  extensive 
survey  of  existing  military  functional  specifications  (as  embodied  in  Military  Standard-490 
B5  specifications).  These  natural  language  descriptions  represent  a first-level  design  of 
the  intended  system.  They  apportion  the  required  processing  into  modules  and  describe 
the  interfaces  between  the  modules  and  the  overall  control  structure.  Because  the 
audience  for  these  descriptions  is  other  people  (as  opposed  to  computers),  they  employ 
the  full  variety  of  detail  suppression  mechanisms  f(>und  in  natural  language,  including 
omitted  parameters  to  actions,  anaphoric  reference,  implicit  or  omitted  control  structure, 
terminology  shifts,  part/whole  interchangeability,  etc.  (These  mechanisms  are  more  fully 
described  in  the  Appendix.)  The  reader  of  the  specification  is  required  to  am'^lify  the  text 
and  determine  f or  himself  which  details  have  been  suppressed. 

Our  study  of  these  specifications  and  their  detail  suppression  mechanisms  led  to  our 
proposed  theory  of  how  people  understand  such  specifications  and  fill  in  the  suppressed 
details.  Our  theory  is  simply  that  these  specifications  are  understood  not  in  a general 
natural  language  context,  but  rather  in  the  much  more  specific  context  that  an  operational 
progrijm  is  being  specified.  Understanding  these  specifications  basically  requires  that  the 
correct  interpretation  of  each  statement  is  chosen  from  several  possible  interpretations  of 
the  natural  language  statement.  The  key  to  our  theory  is  that  these  choices  are  guided 
by  the  statement's  use  in  the  operational  program.  Fortunately,  programs  are  highly 
co'istrained  objects  (one  reason  it  is  so  hard  to  construct  them)  and  therefore  act  as 
effective  filters  of  possible  interpretations.  In  Artificial  Intelligence  terms,  program 
understanding  is  a domain  of  strong  semantic  support. 


The  SAFE  system  is  based  on  this  theory.  It  forms  the  individual  statements  into  a 
program  schema  and  then  attempts  to  "run”  the  schema.  Symbolic  rather  than  actual  data 
is  used  as  input  so  that  general  program  behavior  can  be  analyzed.  At  each  step  in  this 
"running”  of  the  program  a particular  interpretation  must  be  chosen  for  the  current 
statement  before  it  can  be  executed.  The  chosen  interpretation  is  accepted  if  and  only  if 
it  does  not  cause  any  violations  of  the  rules  of  well-formedness  of  programs,  which  are  of 
three  forms.  First,  the  program  must  pass  a set  of  static  (syntactic)  well-formedness  rules 
such  as  "parameters  must  be  used  in  a routine"  and  "the  type  of  an  actual  argument  must 
agree  with  the  corresponding  formal  parameter  type."  Second,  the  program  must  pass  a 
set  of  dynamic  (semantic)  well-formedness  rules,  such  as  (1)  "if  X is  performed  for  the 
purpose  of  Y then  Y must  use  the  results  of  X,"  or  (2)  "the  predicate  of  an  IF  statement 
cannot  be  determinable  from  the  program  itself"  (if  it  were,  then  its  evaluation  is 
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independent  of  the  actual  input  and  therefore  not  really  a conditional  as  expected). 
Finally,  the  program  behavior  cannot  violate  any  constraints  of  the  domain. 

Whenever  one  of  these  rules  is  violated,  the  "run"  is  backed  up  to  the  last  choice 
point  and  a different  choice  is  attempted  (if  no  possibilities  remain,  then  the  previous 
choice  point  is  tried).  This  process  is  continued  until  either  a successful  "run"  is  obtained 
or  all  possibilities  have  been  exhausted.  Interpretations  are  thus  chosen  and  evaluated  in 
the  context  of  how  they  are  used  in  the  run-time  environment  of  the  program.  The 
process  of  "running"  a program  with  symbolic  inputs,  called  meta-evaluation,  has  been 
extensively  developed  by  researchers  interested  in  proving  properties  of  programs.  As 
far  as  we  Know,  this  project  represents  the  first  use  of  meta-evaluation  for  program 
understanding  rather  than  program  proof. 


PROGRESS  Am  ACG}M  PUSH  M ENTS 

A major  milestone  was  achieved  when  the  SAFE  system  transformed  the  informal 
functional  specification  shown  in  Figure  3.2  into  an  operational  program.  The  informality 
of  this  specification  is  shown  in  Figure  3.3,  which  indicates  some  of  the  suppressed  details, 
terminology  conflicts,  and  ambiguous  constructs  contained  in  this  example.  The  formal 
program  produced  as  the  precise  specification  of  the  input  in  Figure  3.2  is  shown  (in  a 
simplified  publication  syntax)  in  Figure  3.4. 

This  example  was  extracted  from  an  actual  Army  functional  specifications  manual. 
The  original  specification  was  much  larger  and  more  complex,  but  the  simplified  version 
retains  the  essential  character  and  style  of  the  original.  It  should  be  noted  from  Figure 
3.2  that  the  actual  input  is  parenthesized  (each  noun-phrase  and  verb-phrase  is 
parenthesized)  so  that  syntactic  parsing  considerations  can  be  avoided.  Such 
parenthesization  does  not,  however,  solve  or  mitigate  the  semantic  interpretation  issue 
discussed  above  (nor  those  shown  in  Figure  3.3)  which  still  remain  for  the  system  to 
resolve  by  meta-evaluation. 

In  an  effort  to  determine  how  difficult  it  is  to  understand  this  particular  informal 
specification  and  convert  it  to  an  operational  abstract  program,  we  asked  several  staff 
members  to  construct  an  abstract  program  corresponding  to  this  specification.  We  asked 
them  not  to  optimize  the  abstract  program  because  our  system  is  not  concerned  with 
efficiency  issues. 

The  problem  was  much  more  difficult  than  we  suspected.  The  subjects  averaged 
eight  hours  to  accomplish  the  task  and  each  subject  had  either  design  or  coding  errors,  or 
both.  Furthermore,  the  programs  produced  were  approximately  the  same  size  as  that 
produced  by  the  system.  One  interesting  result  of  this  test  is  that  the  system  made  one 


iiiWiiWta 


...  , 


Z'VrrT,'"‘i^’~,y~.  ' ~ 


SPECIFICATION  ACQUISITION  FROM  EXPERTS  27 


error*-also  made  by  one  of  the  subjects.  The  error  was  that  copies  of  the  edited 
message  were  distributed  rather  than  copies  of  the  original;  it  was  caused  by  the  fact  that 
the  system  didn’t  understand  that  distinctions  between  original  and  current  state  are 
frequently  suppressed,  and  because  its  current  analysis  of  the  usage  of  produced  results 
is  very  simple.  Both  of  these  deficiencies  are  expected  to  be  corrected  in  the  next 
version. 


PLANS 

Though  the  results  using  this  example  are  very  promising,  and  although  we  have 
attempted  to  build  a general  system  capable  of  handling  a wide  variety  of  specifications 
from  many  different  domains,  it  is  extremely  difficult  to  extrapolate  from  a single  data 
point.  Wu  therefore  are  planning  to  present  several  different  and  more  compiex  examples 
to  the  system  during  the  next  year. 


* ((HESSflCES  ((RECEIVED)  FROfl  (THE  "flUTOOIM-flSC")))  (RRE  PROCESSED)  FOR  (RUTOHRTIC  DISTRIBUTION 
RSSICNflENT)) 

* ((THE  HESSBCE)  (IS  DISTRIBUTED)  TO  (EACH  ((flSSICHEO))  OFFICE)) 

* ((THE  NUnBER  OF  (COPIES  OF  (ft  HESSflCE)  ((DISTRIBUTED)  TO  (RM  OFFICE))))  (IS)  (R  FUNCTION  OF  (UHETHER 
((THE  OFFICE)  (IS  RSSICNEO)  FOR  (("ACTION")  OR  ("INFORHATIOM")))))) 

* ((THE  RULES  FOR  ((EDITING)  (flESSACES)))  (RRE)  (t  ((REPLACE)  (ALL  LINE-FEEDS)  UITH  (SPACES))  ((SAVE) 
(ONLY  (ALPHANUHERIC  CHARACTERS)  AND  (SPACES)))  ((ELININATE)  (ALL  REDUNDANT  SPACES)))) 

* (((TO  EDIT)  (THE  TEXT  PORTION  OF  (THE  HESSAGE)))  (IS)  (NECESSARY)) 

* (THEN  (THE  HESSAGE)  (IS  SEARCHED)  FOR  (ALL  KEYS)) 

* (WHEN  ((A  KEY)  (IS  LOCATED)  IN  (A  HESSAGE))  ((PERF0RI1)  (THE  ACTION  ((ASSOCIATED)  WITH  (THAT  TYPE  OF 
(KEY)))))) 

* ((THE  ACTION  FOR  (TYPE-B  KEYS))  (IS)  (i  (IF  ((NO  OFF(CE)  (HAS  BEEN  RSSICNEO)  TO  (THE  MESSAGE)  FOR 

("ACTION"))  ((THE  "ACTION"  OFFICE  FROM  (THE  KEY))  (IS  ASSIGNED)  TO  (THE  HESSAGE)  FOR  ("ACTION")))  (IF 
((THERE  IS)  ALREADY  (AN  "ACTION"  OFFICE  FOR  (THE  hESSACE)))  ((THE  "ACTION"  OFFICE  FROH  (THE  KEY))  (IS 
TREATED)  AS  (AN  "INFORHATION"  OFFICE)))  (((LABEL  OFFSl  (ALL  "INFORMATION"  OFFICES  FROM  (THE  KEY)))  (RRE 
ASSIGNED)  TO  (THE  MESSAGE))  IF  ((REF  OFFSl  THEY)  (HAVE  (NOT)  (ALREADY)  BEEN  ASSIGNED)  FOR  (("ACTION")  OR 
("INFORMATION")))))) 

* ((THE  ACTION  FOR  (TYPE-1  KEYS))  (IS)  (i  (IF  {(THE  KEY)  (IS)  (THE  FIRST  TYPE-1  KEY  ((FOUND)  IN  (THE 

MESSAGE))))  THEN  ((THE  KEY)  (IS  USED)  TO  ((DETERMINE)  (THE  "ACTION"  OFFICE))))  (OTHERUISE  (THE  KEY)  (IS 

USED)  TO  ((DETERMINE)  (ONLY  "INFORMATION"  OFFICES))))) 


Figure  3.2  Actual  input  for  massage  procassing  axampU 
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by  SAFE  __then  then  dis  tvibu  ted 

r.ESSaCES  received  FROU  the  RUT0DIN-RSC.^SREjRdc£S3£^ReS  nUTOtlOTIC  DICTft»itfrIw(RSSIGH^il]j^ 

to  that  message 

THE  HESSHGE  IS  DISTRIBUTED  TO  ERCH\^GNEOfPrn^. 


THE  NUt'BER  OF  COPIES  OF  R HES^RCE  DISTRIBUTED  TO  RM  OFFICE  IS  fl  FUNCTION  OF  IIHETHER  THE  OFFICE 
to  that  message 
IS  fiSSICNEO^^FOR  ACTION^ INFORflRTION. 

definition^ ^ in  text  of  message 

THE  RUteS  FOR^EOnni^  (lESSflCE^  RRE  (1)  REPLRCE  RlU  LINE  FEEOS/vUITH  SPACES  (2)  SAVE  ONLY 

from  text 


RLPKRNUtlERIC  CHARACTERS  RNOl 


SPACES  RNO  THEN  (3)  ELUlINRTE  RLL  REDUNDANT  SPRCESy^. 


* IT  IS  NECESSARY  To(eOIT  THE  TEXT  PORTION  OF  THE  F.ESSACr^ 


text  of  the  

THE/^t1£SSRGE  IS  THEN (SEARCHEdjFOR  ALL  KEYS. 


the  text  of 


* UHEN  A KEY  IS  LOCATED  IH^A  KESSRGE,  PERFORh(t^  ACTION  ASSOCIATED  HITH  THAT  TYPE  »F  KEY., 


THE(^T10N  for  type-0  KEYs)iS!  if  NO  ACTION  OFFICE  HRS  BEEN  ASSIGNED  TO  THE  nESSAGE,  THE 

assigned  to  otherwise 

ACTION  office  FftOft^THE  KEY  13  RSSIGNEO  TO  THE  ilESSAGE  FOR  ACTION. /^IF  THERE  IS  AlREAOY  AN 


ACTION  OFFICE  FOR  THE  MESSAGE,  THE  ACTION  OFFICE  FROM  THE  KEY  (iS  TRERTeT^RN  IMFCRMATION 

for  key  for  -information 

office^,  all  information  OFFICES  FROM  THE  KEY  RRE  ASSIGNED  TO  THE  MESSAGE^JF  THEY  HAVE  NOT 

to  the  message 


ALREADY  BEEN  ASSIGNED  FOR  ACTION  OR  INFOR.iATION^. 


THE  ACTION  FOR  TYPE-l  KEYS  IS:  IF  THE  KEY  IS  THE  FIRST  TYPt-1  KEY  FOUND  IN  THE  MESSAGE  THEN 


of  the  message 

THE  KEY  IStUSED  TO  DETERMINE^THE  ACTION  OFFICE^.  OTHERliISE  THE  KEY  1S(US£D  TO  DETERMINE  ONLy) 


of  the  message 


INFORMATION  OFFICES^ 


Figure  33  specification  deficiencies  of  message  processing  example 
(by  conuentional  programming  standards) 
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(UtdJNEVER  (r*c«iv«  iMss<9t  TROfl  autodin-atc  BV  taf*) 

(adit  taxt  OF  matsaga) 

(taarch  taxt  OF  Mttaga  FOR  (CREATE  THE  SET  OF  Kays)) 

(diatr ibuta-procata#!  Mttaya)) 

(dittrlbuta-procasifl  (Mitaya) 

(FOR  ALL  oMicai  UHICH  ARE  (ataiynad  e(<ica  TO  aaiaaga  FOR  ANYTHING) 

(diatr ibuta-praeata#2  Mataya  offica))) 

(dlstr lbuta-proeaac#2  (Mtaaga  of(ira) 

(FOR  ((jnctionfl  (TRUTH-VALUE  OF  (aaaiqnad  oHica  TO  Mtaaya  FOR  action)) 

(TRUTH-VALUE  OF  (aatiynad  offica  TO  aattaya  FOR  InforMtion))) 
TIHES  (diitributa  A copy  UHICH  IS  A copy  OF  Miiaya  AND  locatad  AT  tafa 
FROn  tafa  TO  location  OF  offica))) 

(adit  (taxt) 

(FOR  ALL  iina-foads  UHICH  ARE  IN  taxt 

(rapiaca  tina-faad  IN  taxt  BY  (CREATE  AN  OROERED  SET  OF  ipacai))) 

(kaap  THE  (union  (CREATE  THE  SET  OF  aiphanunaric  charactara  IN  taxt) 

(CREATE  THE  SET  OF  apacaa  IN  taxt)) 

FROM  taxt) 

(FOR  ALL  apacaa  UHICH  ARE  IN  taxt  AND  radundant  IN  taxt 
(ranova  spaca  FRO**  taxi*) 

(UHENEVER  (tocata  P kay  IN  taxt  OF  Maaaaya  AT  POSITION  ANYffllNC) 

(CASE  (typa  OF  kay) 

(typa-0  (typa-9-act ion  maaaaya  kay)) 

(typa-1  (typa-l-act ion  iiaaaaya  kay)))) 

(type-8-act ion  (maaaaya  kay) 

(IF  (NOT  (EXISTS  action  offica  FOR  mt.aaya)) 

THEN  (aaaiyn  THE  action  offica#!  FOR  kay  TO  maaaaya  FOR  action) 

ELSE 


(traat  action  oficafZ  FOR  kay  AS  information  offical2  FOR  kay 
IN  (IF  (NOT  (aaaiynad  o(ftca#2  TO  maaaaya  FOR  action  OR  inforNtion)) 

THEN  (aaaiyn  offica#2  TO  moaiaga  FOR  information)))) 

(FOR  ALL  offiea#3  UHICH  ARE  (aaaiynad  o(fica#3  TO  kay  FOR  information)) 

(IF  (NOT  (aaaiynad  officafS  TO  maaaaya  FOR  action  OR  information) 

THEN  (aaaiyn  offica#3  TO  maaaaya  FOR  information)))) 

(typo-l-act ion  (massaya  kay) 

(IF  kay  - (kayfl  UHICH  IS  (SEARCH  HISTORY  FOR  FIRST 

(iocata  typa#!  kay#l  IN  taxt  OF  maaaaya  AT  poaition  ANYTHING))) 

THEN  (datarmina  THE  action  offica  FOR  maaaaya 
BY  ( typa-0-act ion  massaya  kay)) 

ELSE  (datarmina  ONLY  THE  information  offica  FOR  maaaaya 
BY  (IF  (EXISTS  action  offica  FOR  maaaaya) 

THEN  (traat  action  offica#!  FOi<  kay  AS  information  offica#!  FOR  kay 
IN  (IF  (NOT  (aaaiynad  offica#!  TO  maaaaya  FOR  action  OR  information)) 
THEN  (aaaiyn  offica#!  TO  maaaaya  FOR  information)))) 

(FOR  ALL  offica#2  UHICH  ARE  (aaaiynad  offica#2  TO  kay  FOR  information) 
(If  (NOT  (aaaiynad  offica#2  TO  maaaaya  FOR  action  OR  information)) 
THEN  (aaafyn  offica#2  TO  maaaaya  FOR  information)))))) 


Figure  3.4  Program  created  by  prototype  system 
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APPENDIX 

WHAT  NATURAL  LANGUAGE  CONSTRUCTS  ARE  IMPORTANT 
FOR  PROGRAM  DESCRIPTIONS 

Natural  language  program  descriptions  seem  to  depend  upon  a particular  model  of 
the  (relevant)  world  populated  by  objects  of  various  types  having  ce:  rain  attributes  which 
are  relationships  between  themselves  and  other  objects.  This  collection  of  objects  and 
their  relationships  can  be  classified  as  a model  because  the  objects  must  obey  certain 
rules  (both  static  and  dynamic)  that  limit  the  allowed  states  the  model  can  adopt.  These 
rules  are  the  "physics"  of  the  model. 

With  such  a model  as  a basis,  a program  description  corresponds  to  rules  for 
forming  sequences  of  actions  that  will  guarantee  that  the  model’s  behavior  (as  constrained 
by  the  physics)  additionally  meets  some  other  criteria— the  goal  of  the  process.  The 
behavior  is  specified  either  as  the  final  state  of  the  model  or  as  the  succession  of  states  it 
assumes.  The  sequence  formation  rules  are  the  analog  of  control  statements  in 

conventional  programming  languages. 

Thus,  as  a first  approximation,  a language  suitable  for  natural  language  program 

descriptions  must  be  capable  of  defining  types  of  objects,  instances  of  these  objects  with 

specific  attributes  and  relationships  with  other  instances,  constraints  on  the  allowable 
states  that  the  collection  of  objects  can  assume,  actions  which  modify  the  objects  and  their 
interrelationships,  and  rules  for  forming  sequences  of  these  actions  to  achieve  some  goal. 
Such  a language  closely  approximates  the  current  notion  of  an  abstract  programming 
language. 

The  natural  language  model  differs  from  the  abstract  program  model  in  two 
fundamental  ways:  Fir n the  natural  language  model,  it  is  assumed  that  any  desired 

information  concerning  the  current  or  previous  states  of  the  model  can  be  directly 

retrieved  from  the  model;  thus  all  information  is  viewed  as  primary.  Second,  all  the 
consequences  of  an  action  are  not  specified  as  part  of  the  action’s  description,  but  only 
the  portion  directly  relatea  to  the  actions.  The  others  can  be  derived  from  those 
specified.  These  rules  of  information  derivation  are  called  inference  rules,  and  they 
permit  the  natural  language  model  to  ignore  the  distinction  between  primary  and  derived 
information  and  to  specify  only  the  primary  effects  of  an  action.  They  also  permit  the 
derivation  of  information  to  be  decoupled  from  both  how  the  information  used  in  the 
derivation  was  itself  generated  and  how  the  desired  information  is  used.  They  thus  deal 
.'ith  the  consistency  of  the  model  in  any  state  rather  than  the  movement  between  states. 
The  task  of  maintaining  the  consistency  of  the  state  is  transferred  to  the  system  through 
these  inference  rules.  Thus  the  natural  language  model  must  embody  inference  rules  and 
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must  use  them  to  meintain  tne  consistency  of  the  model  state  tts  it  is  changed  by  actions. 
Using  this  natural  language  model  as  a basis,  we  can  now  disciiss  the  three  broad 
categories—declarative,  naming,  cont.'ol— of  constructs  which  appear  in  natural  language 
program  descriptions. 


Declarative  Informatien 


Declarative  information  is  used  to  help  the  translator  select  the  appropriate 
interpretation  of  procedural  constructs.  Most  of  this  information  (such  as  t*/pe,  relation, 
constraints,  and  inference  rules)  has  already  been  described  above.  The  issues  here  are 
that  in  natural  language  descriptions  this  information  is  mixed  with  the  procedural 
description  rather  than  separated  from  it  and  the  use  of  the  information  extends  beyond 
static  characteristics  to  dynamic  behavioral  ones.  Thus,  constraints  are  often  used  to  help 
eliminate  interpretations  that  will  cause  the  constraint  to  be  violated. 


There  is  one  additional  type  of  declarative  information,  called  expectations,  not 
already  discussed.  These  are  promises  that  certain  things  will  occur  or  that  the  program 
being  described  fits  together  in  certain  ways.  For  example  [all  the  examples  are  drawn 
from  the  program  description  in  Figure  3.2]: 


• The  message  is  processed  for  distribution”  - This  sets  up  the  expectations 
that  processing  precedes  distribution  and  that  the  processing  produces  some 
results  used  by  distribution. 


As  with  the  other  declarative  information,  these  expectations  can  be  used  to 
eliminate  possible  interprrTtions  which  do  not  fulfill  the  expectations. 


Naming  Centtruett 


In  programming  languages  variables  are  normally  given  unique  names  or--if  names 
are  reused—precise  scoping  rules  provide  a unique  interpretation.  In  natural  language,  on 
the  other  hand,  objects  are  almost  never  given  names;  instead,  context  in  conjunction  with 
a naming  construct  provides  a unique  reference.  Thus  both  a context  mechanism  and  the 
following  variety  of  naming  constructs  must  be  provided. 


Deteriptive.  A set  of  associations  is  given  which  uniquely  selects  a particular 
object  from  those  in  the  current  context  or  the  set  of  all  objects  of  the 
specified  type.  For  example: 


■ 
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• The  office  assigned  to  the  key  for  action"  - If  it  is  ass>umed  that  the 
reference  to  "Key"  is  unique  and  that  only  one  office  is  assigned  to  that 
key  for  action,  then  this  descriptive  reference  is  also  unique. 

B.  SimpU  typed  refereneet.  Only  the  type  of  the  desired  object  is  specified;  the 
resolution  must  be  provided  either  by  a unique  instance  of  that  type  in  the 
context  or  by  the  operations  performed  on  the  object.  For  example: 

e The  message  is  distributed"  - Context  is  used  to  determine  that  the 
received  message  is  the  desired  one. 

• "Replace  all  line-feeds"  - Using  the  line-feeds  (i.e.,  replacing  them  by 
spaces  in  the  text  of  the  message)  requires  that  the  referenced  line-feeds 
be  in  the  text.  Thus  only  line-feeds  in  the  text  satisfy  this  typed 
reference. 

C.  Approximate  refereneet.  Th.^  stated  reference  doesn’t  specify  the  necessary 
relations  to  determine  thu  desired  object,  which  can  be  either  explicit  as  in 
the  generalized  prepositions  below  or  hidden  so  that  only  a failure  of  the 
referenced  object  to  satisfy  some  usage  criteria  indicates  the  necessity  to 
reinterpret  the  reference  as  an  appropriate  reference  to  some  closely  related 
object.  Resolution  of  this  type  of  reference  requires  both  context  and  usage 
analysis.  Two  broad  subcategories  are: 

Cl.  Generalized  prepositiont.  When  a strong  association  exists  between 
objects,  a preposition  may  sometimes  be  used  in  place  of  the 
association  to  relate  the  objects. 

• The  action  office  from  the  key"  - The  word  "from"  indicates  that 
some  unspecified  relation  associates  office,  action,  and  key.  In  this 
example,  this  association  is  the  office  assigned  to  the  key  for  action. 
The  reference  is  then  treated  as  descriptive. 

C2.  Hidden.  Reference  is  made  to  an  object  when  a closely  related  one  (in 
this  case  a subpart)  is  desired. 

• "The  message  is  then  searched"  - Although  "message"  is  specified, 
only  the  text  portion  has  the  appropriate  attributes  to  be  searched; 
thus  it  is  the  intended  reference. 

0.  Hitting  operanit.  In  many  situations  operands  to  associations  or  actions  are 
completely  omitted  from  the  natural  language  program  descriptions.  Such 
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omissions  are  possible  only  when  the  context  and  usage  constraints  are 
strong  enough  to  determine  the  reference,  or  when  the  particular  reference  is 
irrelevant  or  the  entire  class  of  possible  referents  is  intended.  In  addition  to 
using  such  context  and  usage  information,  the  omission  must  be  recognized  to 
initiate  these  mechanisms;  such  recognition  depends  upon  knowing  what 
operands  are  required  for  each  association  and/or  action  used. 

• The  message  is  distributed  to  each  assigned  office”  - The  "assign" 
association  requires  three  operands:  an  office,  a type  of  assignment 
(either  action  or  information),  and  an  object  being  assigned  to  (either 
message  or  key).  Only  one  of  the  three--office"is  specified.  Thus  the 
object  being  assigned  to  is  omitted  and  context  is  used  to  determine  that 
the  message  should  be  distributed  only  to  those  offices  assigned  to  that 
message.  Similarly,  context  is  used  to  determine  that  offices  assigned  for 
either  action  or  information  (the  only  two  possibilities)  are  intended  for 
distribution. 


Control 

As  with  naming,  natural  language  program  descriptions  use  seversi  control 
constructs  which  do  not  exist  in  programming  languages  and  which  permit  a very  different 
organization  for  these  descriptions.  Instead  of  a whole  composed  of  highly  structured  and 
tightly  connected  parts,  as  in  programming  languages,  they  form  a loose  confederation  of 
unconnected  fragments  held  together  only  by  constructive  efforto  based  on  context  and 
usage. 


This  constructive  effort  is  exactly  that  needed  to  transform  the  description  into  the 
program  control  structure.  It  should  not  be  surprising  that  the  control  structure  has  been 
suppressed  and  dispersed  in  descriptions  because  these  descriptions  are  intended 
primarily  for  understanding,  not  execution.  Program  descriptions  thus  highlight  the 
processing  for  the  normal  case  by  presenting  it  first,  followed  by  descriptions  of  any 
exceptions  and  how  these  exceptions  should  be  processed.  They  in  turn  are  similarly 
described,  so  that  any  exceptions  to  an  exception  will  follow  the  description  of  that 
exception. 

The  structure,  then,  of  natural  language  program  descriptions  is  that  a fragment  (a 
piece  of  the  description  with  infernal  conventional  control  structure)  is  followed  (not 
necessarily  immediately)  by  a set  of  exceptions  that  specify  the  application  criteria  and 
the  processing  (as  a fragment)  for  those  cases  which  satisfy  the  criteria.  This  is  exactly 
opposite  to  the  order  found  in  programming  languages,  in  which  all  the  special  cases 
precede  the  normal  case.  Details  are  similarly  suppressed  in  a fragment  to  promote 
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uivjerstanding,  and  the  amplifications  occur  later  in  fragments  which  indicate  what  is  being 
amplified  and  what  the  amplification  is. 

Constructing  the  program  control  structure  for  a program  description  thus  involves 
integrating  the  fragmen's,  which  requires  that  the  type  of  each  fragment  be  identified  as  a 
normal  case,  exception,  or  amplification  specification.  For  each  fragment  of  the  latter  two 
types,  the  fragment  being  modified  or  amplified  must  be  ideritified  (this  is  a naming 
problem  similar  to  those  described  above). 

Amplification  can  be  treated  as  substitutions  for  the  named  construct  within  the 
amplified  fragment.  There  are,  however,  two  problems  with  exceptions.  The  first  is  the 
relative  ordering  of  multiple  exceptions  to  a fragment.  Normally  such  ordering  is  not 
explicitly  stated  and  must  be  determined  by  the  type  of  overlap  between  thei.  applicable 
cases  and/or  processing  assumed  in  the  modification.  As  part  of  this  ordering  problem,  it 
must  also  be  determined  (by  a similar  analysis)  whether  or  not  a case  that  satisfies  the 
criteria  for  an  exception  should  then  be  tested  against  the  criteria  of  other  exceptions 
and/or  processed  by  the  normal  case.  The  second  problem  with  exceptions  is  that  the 
processing  to  be  performed  might  not  be  directly  specified,  but  rather  given  as  a 
modification  of  or  a similarity  to  already  specified  processing,  which  requires  that  a new 
category  of  "editing"  operations  (such  as  bypasr..  include,  except,  treat  as,  inhibit,  enable, 
etc.)  must  be  understood  and  handled. 
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INTRODUCTION 

The  Protection  Analysis  Project  is  an  ongoing  research  effort  toward  improving  the 
security  of  existing  general-purpose  resource-sharing  operating  systems  by  finding  errors 
in  their  protection  mechanisms.  This  task  has  come  to  be  called  “protection  evaluation." 
The  problem  is  of  obvious  importance  in  view  of  the  investment  existing  systems 
represent,  their  expected  lifetime,  and  their  insecurity.  It  is  well  known  that  current 
general-purpose  operating  systems,  due  to  their  size  and  complexity,  usually  contain  a 
large  number  and  variety  of  errors  even  after  having  been  in  service  for  years.  These 
include  security  errors--indicated  by  the  fact  that  skillful  penetration  efforts  directed 
against  these  systems  invariably  succeed.  The  task  of  improving  such  systems  is  urgent, 
since  many  are  installed  in  governmental,  commercial,  and  military  environments  in  which 
the  requirement  for  security  (in  terms  of  the  magnitude  of  losses  from  accidental  or 
intentional  violations)  is  strong  and  immediate.  These  losses  will  be  reduced  in  proportion 
to  the  cost-effectiveness  of  the  available  error-finding  tools. 

APPROACH 

There  are  several  possible  approaches  to  the  elimination  of  protection  errors  in 
general-purpose  operating  systems.  Probably  the  most  elegant  and  formal  is  the  use  of 
program  verification  techniques,  i.e.,  proving  a program  correct  with  respect  to  a collection 
of  mathematical  assertions.  To  use  program  verification  for  protection  evaluation,  three 


tasks  must  first  be  completv’d: 

1.  The  protection  policy  to  be  enforced  must  be  formalized. 

2.  The  formalized  protection  policy  must  be  proved  complete  and  consistent. 

3.  fhe  formalized  protection  policy  must  be  translated  into  program  verification 
assertions. 

Program  verification  techniques  would  then  be  used  to  prove  the  assertions  correct  with, 
respect  to  the  operating  system  code. 

There  ar«,  however,  numerous  problems  associated  with  the  above  app'^nach  First, 
no  one  has  been  able  to  write  the  formal  protection  policy  fc."  an  operating  system,  let 
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alone  address  the  problems  of  proving  that  policy  consistent  and  complete  and  of 
translating  it  into  program  verification  assertions.  Furthermore,  current  program 
verification  techniques  are  not  powerful  enough  to  handle  the  language  constructs  used  in 
contemporary  general-purpose  operating  systems.  Finally,  there  is  the  related  problem 
that  contemporary  operating  systems  are  too  large  and  complex  to  be  considered  as  viable 
candidates  for  verification. 

Research  is  being  directeJ  «o  th«>  solution  of  each  of  the  above  problems.  For 
example,  research  is  currently  under  way  in  formulating  protection  policy.  Examples 
include  the  "star  -property"  [Bell  73]  and  "data  security"  [Popek  76].  Considerable  effort 
is  also  being  expended  to  improve  and  automate  program  verification  techniques*  and  to 
develop  programming  languages  for  producing  operating  systems  which  are  more  amenable 
to  program  verification  techniques  [Lampson  76].  Finally,  research  is  being  directed  at 
decreasing  the  size  of  existing  systems  [Schroeder  75]  and  creating  systems  based  on 
small  kernels  [Panel  74], 

White  an  approach  based  on  the  use  of  formal  techniques  is  desirable,  the 
aforementioned  problems  prevent  their  application  to  contemporary  systems.  What  then 
can  be  done?  Two  basic  problem  areas  require  attention: 

1.  Derivation  of  the  policy  against  which  the  correctness  of  an  operating  system’s 
protection  mechanisms  will  be  judged. 

2.  Development  of  less  formal  evaluation  procedures  to  compare  the  protection 
policy  with  more  immediately  applicable  operating  system  code. 

The  Protection  Analysis  project  is  addressing  these  problems  in  the  following  ways. 

DtrivatioH  of  Enforcement  Polieiet 

While  it  is  not  presently  possible  to  specify  a total  protection  policy,  let  alone  verify 
its  completeness  and  consistency,  there  is  a basis  for  empirically  identifying  elements  of 
that  policy  from  observed  protection  errors  in  existing  systems.  Because  protection 
errors  are,  in  fact,  nothing  more  than  violations  of  some  protection  policy,  from  a collection 
of  observed  protection  errors  it  is  possible  to  derive  the  protection  policies  violated. 

identification  of  Evaluation  Tools  and  Techniques 

The  second  problem  is  to  evaluate  the  protection  mechanisms  of  operating  systems 
with  regard  to  the  derived  policies.  As  stated  previously,  general-purpose  program 
verification  techniques  are  not  powerful  enough  to  handle  programs  of  the  size  and 
complexity  of  contemporary  general-purpose  operating  systems.  However,  it  is  possible 
to  develop  for  a single,  specific  element  of  protection  policy  a special-purpose  evaluation 
tool  or  technique. 


*S«t  Saction  1 of  thii  roport. 
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In  summary,  the  ISi  approach  consists  of  deriving  protection  policies  from  known 
protection  errors  and  developing  individual'  search  techniques  capitalizing  on  these 
policies.  (For  a more  detailed  discussion  of  the  issues  involved,  see  [Carlstedt  75].) 


PROGRESS 

During  the  past  year,  an  analysis  was  completed  of  a collection  of  known  protectioi  i 
errors  in  operating  systems.  The  goal  of  this  analysis  was  to  categorize  the  errors  as  t ) 
type.  As  a result  of  the  study,  it  was  found  that  all  of  these  errors  fell  into  one  or  mo'S 
of  ten  categories. 

The  remaining  research  effort  has  focused  on  the  generation  of  operating  system 
evaluation  procedures.  The  three  error  categories  for  which  investigations  have  been 
completed  are:  consistency  of  data  over  time;  validation  of  operands;  and  residuals. 
Research  continues  for  other  categories. 

CoHtiueney  of  Duto  over  Time 

Operating  systems  continuously  make  protection-related  decisions  based  on  data 
values  contained  within  the  system  data  base  as  well  as  on  values  which  have  been 
submitted  to  and  validated  ay  the  system.  In  order  for  a correct  protection  decision  to  be 
made  (in  the  absence  of  other  types  of  protection  errors),  the  data  must  be  in  a consistent 
state,  i.e.,  the  value  or  structure  of  the  data  on  which  the  protection  decision  is  made  must 
be  in  some  specific  relationship  with  other  data  in  the  system,  and  must  remain  in  that 
relationship  during  the  interval  in  which  the  protection  decision  is  made. 

Protection  Errors  in  Operating  Systems:  Inconsistency  of  a Single  Data  Value  Over 
Time  [Bisbey  75]  describes  the  general  error  type  as  well  as  a particular  instantiation,  i.e., 
those  errors  resulting  from  inconsistencies  in  parameters  supplied  to  the  operating 
system. 

Validation  of  Operands 

Within  .'jn  operating  system,  there  are  numerous  operators  responsible  for 
maintaining  the  system’s  data  base  and  for  changing  the  protection  state  of  processes  or 
objects  knov/n  to  the  system.  Many  of  these  operators  are  critical  in  the  sense  that  if 
invalid  or  unconstrained  data  are  presented  to  them,  a protection  error  results. 

Protection  Errors  in  Operating  Systems:  Validation  of  Critical  Conditions  [Carlstedt 
76]  investigates  the  validation  of  conditions  attached  to  critical  operators  and  their 
operands,  especially  when  those  operands  can  be  readily  influenced  by  users.  A 
companion  research  report  [Bisbey  76]  describes  a specific  technique,  Data  Dependency 
Analysis,  for  automatically  finding  data  flow  paths  within  operating  systems,  thereby 
making  it  easier  to  detect  errors  of  this  type. 
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Re$idual$ 

A widely  recognized  error  type  is  that  of  the  "residual  ” i.e.,  information  which  is 
"left  over"  in  an  object  when  the  object  is  deallocated  from  one  process  and  allocated  to 
another.  Several  types  of  residual  errors  exist,  including 

• /keess  FetiduaU.  Incomplete  revocation  or  deallocation  of  the  access 
capabilities  to  the  object  or  cell. 

• Attribute  Residualt.  Incomplete  destruction  of  the  cell’s  context  with  other 
cells  or  objects,  and  of  old  values  within  the  cell. 

Protection  Errors  in  Operating  Systems:  AUoeation/Deallocation  Residuals 

[Hollingworth  76]  examines  the  sources  of  these  errors  and  discusses  strategies  for  them 
in  operating  systems. 

Future  research  effort  will  focus  on  the  development  of  evaluation  procedures  for 
finding  other  major  error  types. 


IMPACT 

The  work  described  here  in  will  have  an  impact  in  several  areas,  most  immediately  in 
the  evaluation  of  existing  operating  systems  with  respect  to  the  reliability  of  their  security 
mechanisms.  The  empirical  basis  of  the  research  makes  it  easy  to  incorporate  new  error 
types  and  detection  techniques  should  they  be  identified.  The  evaluation  techniques  can 
also  be  used  in  computer  acquisition  as  part  of  a set  of  standard  tests  for  system 
acceptance.  Additionally,  the  data  base  of  errors  and  error  types  is  useful  in  the  repair 
or  modification  of  existing  systems;  it  could  form  the  basis  for  a "best  practic^js  manual,” 
i.e.,  a discussion  of  errors  and  problems  that  should  be  avoided  in  the  design  of  future 
systems  and  protection  mechanisms.  Finally,  the  analysis  needed  to  derive  er  or  types 
and  to  develop  associated  error  detection  algorithms  yields  insights  that  contribute  to  a 
deeper  understanding  of  protection  itself. 
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INTRODUCTION 

The  increasing  sophistication  of  weapons  systems  and  decreasing  time  frame  for 
making  decisions  make  it  essential  to  provide  the  military  commander  better  quality 
information  faster,  even  though  manpower  has  been  reduced  by  the  conversion  to 
all-volunteer  forces.  With  today’s  technology,  messages  can  traverse  several  thousand 
miles  in  fractions  of  a second,  but  hours  are  lost  at  either  end,  both  in  entering  the 
message  into  the  communications  system  and  in  delivering  it  to  the  man  who  can  act  on  it. 

The  lA  project  is  studying  the  application  of  on-line,  interactive  computer 
technology  to  the  military  message  handling  problem  and  is  preparing  an  operational  test 
for  a system  designed  to  help  solve  the  problem.  On  the  basis  of  the  ARPANET  message 
system  experience,  we  are  confident  that  such  a service  has  a high  payoff  to  the  military. 
Not  only  can  formal  message  preparation  and  delivery  become  faster  and  more  reliable, 
but  the  processing  facilities  provided  can  also  be  put  to  new  use;  for  example,  with  such  a 
service  the  status  of  a message  is  automatically  available  at  all  stages  from,  preparation  to 
delivery.  Much  more  detailed  accounting  and  auditing  is  easy  to  maintain,  providing  a 
better  understanding  of  the  basic  communication  process.  Entirely  new  facilities  become 
available  as  well:  for  example,  using  the  message  service  to  alert  individual  users  when 
certain  events  have  occurred  (e.g.,  "the  message  from  Capt.  Jones  that  you  were 
expecting  has  arrived").  Automated  suspense  files,  calendars,  etc.  are  also  simple  to 
provide. 

Perhaps  the  most  important  contribution  of  such  a system  is  that  it  makes  available 
a secure,  informal  (off-the-record)  message  facility.  This  "electronic  memo  pad"  is  swift 
and  convenient  to  use  and,  unlike  the  telephone,  does  not  require  the  simultaneous 
attention  of  sender  and  receiver. 

The  project  is  specifically  directed  to  the  military  communication  environment,  and 
even  more  specifically  to  nonexpert  users.  The  most  effective  way  to  introduce  such  a 
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service  into  the  military  community  is  by  means  of  an  operational  test  at  a military  site, 
which  will  serve  a twofold  purpose:  It  will  demonstrate  the  utility  of  an  on-line  message 
service  in  an  environment  credible  and  comprehensible  to  military  planners,  and  allow 
system  planners  to  understand  the  impact  of  such  a system  on  the  user  organization  and 
to  evaluate  the  cost  versus  benefits  of  its  various  features.  System  builders  will  obtain  a 
better  understanding  of  the  implementation  a;id  delivery  issues. 


BACKGROUND 

Although  the  lA  project  actually  began  in  tho  fall  of  1973,  its  roots  reach  back  to  a 
five-week  study,  conducted  on  behalf  of  ARPA,  of  the  military  ccm.munications  on  the 
island  of  Oahu  [1].  This  study  was  initiated  at  the  reque.it  of  the  Secretary  of  Defense  for 
Telecommunications  as  a part  of  a Navy  program  called  COTCO,  whose  mission  was  to 
consolidate  and  improve  communications  on  Oahu.  Until  ARPA’S  involvement,  COTCO 
advocated  conventional  data  processing  solutions.  The  IS)  repo:  t recommended  a complete 
island-wide  interactive  writer-to-rcader  message  service  electrically  coupled  to  AUTODiN 
(the  military’s  backbone  communication  system);  it  was  submitted  by  ARPA  to  DoD,  where  it 
excited  considerable  interest  but  was  generally  regarded  as  too  radical  to  be  included  in  a 
production  system  without  a better  appreciation  of  its  cost  and  benefits. 

Recognizing  this,  ISI  cooperated  with  ARPA  in  developing  a sensible  military  message 
program  and  in  making  the  case  to  the  military  establishment  for  the  usefulness  of  a test 
of  an  on-line  interactive  message  service  in  an  operational  military  environment.  From 
such  a test  one  can  learn  what  features  are  valuable,  how  the  service  is  used,  and  how  it 
affects  the  way  the  Uoer  organization  does  its  business.  Th’s  information  is  essential  for 
long-range  military  communication  planning  and  for  proper  implementation  of  production 
systems. 

By  the  summer  of  1975  ARPA  organized  a separate  program  for  military  message 
handling.  In  December  1975  the  effort  culminated  with  the  signing  of  a memorandum  of 
agreement  between  Commander -in-Chief,  Pacific  (CINCPAC);  Commander,  Naval  Electronics 
Systems  Command  (NAVELEX);  Commander,  Naval  Telecommunications  Command, 
(NAVTELCOMM);  and  Director,  Defense  Advanced  Research  Projects  Agency  (DARPA).  This 
memorandum  calls  for  a test  of  such  an  experimental  message  service  to  be  run  at 
CINCPAC  staff  Headquarters,  Camp  Smth,  Oahu  The  experiment  is  designated  to  begin  in 
January  1977  and  to  last  for  two  years.  Funding  is  to  be  shared  jointly  by  NAVELEX  and 
DARPA. 

INFORMATION  AUTOMATION  PROJECT 

The  lA  project  was  started  at  ISI  in  the  fall  of  1973  with  a twofcM  goal:  1)  to 
develop  the  technology  for  providing  on-line  computer  services  directly  to  users  who  are 
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neither  speciali*its  m computer  science  nor  specifically  trained  operators  and  2)  to  develop 
ar  on-line,  interactive,  writer-to-reader  message  service  for  the  military  community.  The 
two  goals  are  in  fact  indivisible.  The  military  action  officers  who  send  and  receive 
messages  are  not  computer  specialists.  For  the  service  to  be  useful,  an  interface  must  be 
provided  that  Knows  a great  deal  about  each  individual’s  habits,  thus  making  his  use  of  the 
service  seem  easy  and  natural  to  him. 


The  military  have  been  users  of  an  electronic  message  service  for  many  years.  At 
each  organization  the  service  has  always  been  handled  as  an  over-the-counter  business, 
an  outgrowth  of  its  development  from  telegraphy.  Over  this  long  history  much  procedure 
and  policy  has  developed.  It  is  the  over-the-counter,  manual  handling  of  messages  that 
the  on-line  service  is  designed  to  replace.  This  new  system  will  bring  a new  style  of 
operation  which  will  affect  some  of  the  old  policy  and  alter  much  of  the  procedure.  To  be 
a success,  an  on-line  message  service  must  provide  the  improvements  inherent  in 
automation  without  overly  disrupting  the  traditional  patterns  and  procedures  that  are 
Known  to  work.  The  manual  nature  of  today’s  message  service  is  somewhat  cumbersome, 
but  it  is  extremely  flexible;  each  command  or  organization  is  able  to  tailor  its  procedures 
to  its  own  needs.  One  of  the  unique  goals  of  the  lA  message  service  is  to  provide  this 
tailorability. 

To  adequately  support  military  message  handling  the  organizational  structure  of  the 
user  community  must  be  reflected  in  this  service.  For  example,  the  rules  about  who  can 
access  what  message  files  and  who  can  release  what  messages  must  be  carefully  modelled. 
By  definition,  formal  military  message  traffic  flows  between  commanders  of  organizations, 
even  though  the  messages  nearly  always  originate  anj  terminate  at  much  lower  levels. 
This  necessitates  special  "coordination"  or  "staffing"  procedures  on  outgoing  messages 
(which  require  approval  up  the  entire  chain  of  command)  and  complicates  the  distribution 
of  incoming  messages.  The  lA  military  message  service  is  unique  in  its  approach  to  these 
problems,  making  it  possible  to  retain  these  formalisms  to  any  degree  found  necessary  in 
the  tests. 

It  is  also  necessary  that  the  on-lira  service  be  easy  to  use.  It  is  certainly  easier  to 
type  "send  for  coordination"  than  to  hand-carry  a draft  message  around  to  each 
coordinator.  However,  by  automating  this  transmission  we  are  faced  with  making  the  use 
of  terminals  competitive  with  paper  and  pencil.  Toward  this  end  the  lA  project  is 
developing  scanning  and  editing  aids  that  currently  do  not  exist.  For  instance,  to  facilitate 
integration  of  comments  and  changes  from  several  coordinators,  the  service  offers  the 
ability  to  compare  two  versions  of  the  same  paragraph  on  separate  windows  of  the  CRT 
screen,  highlighting  the  differences  by  making  the  changed  characters  brighter. 

The  proposed  lA  message  service  is  divided  into  two  stages;  preparation  and 
delivery.  The  former  stage  includes  the  creation  of  the  draft  message  and  the 
coordination  of  this  draft  with  other  users  until  it  is  signed  off  for  release.  For  this  stage 
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the  lA  message  service  provides  a special-purpose  editing  program  which  understands 
message  formats  and  checks  that  the  contents  o»  the  various  fields  are  legitimate.  The 
editor  is  structured  so  that  a coordinator’s  editing  of  a message  is  stored  as  a special 
change  file  rather  than  as  actual  modifications  to  the  original. 

The  author  of  the  draft  message  controls  the  sequence  and  timing  of  delivery  of  the 
draft  to  coo'^dinators.  The  message  can  proceed  serially  or  in  parallel  (or  any  combination 
of  the  two).  The  author  can  have  the  message  returned  to  him  after  each  signoff  (so  he 
can  incorporate  the  changes),  he  can  ask  that  he  simply  be  notified  after  each  signoff,  or 
he  can  let  the  coordination  delivery  proceed  automatically. 

Often  a coordinator  of  a message  wishes  to  obtain  the  opinions  of  others  on  his 
staff  before  he  signs  off.  The  iA  message  service  allows  the  coordinator  to  "delegate"  to 
as  many  people  as  he  wishes  the  capability  to  comment  and  edit  the  message  (each 
delegate  edits  from  the  origin--''  and  creates  his  own  change  file).  If  so  inclined,  the 
coordinator  may  also  delegate  the  signoff  rcsponsibiiity,  but  this  is  restricted  to  a single 
delegate  only.  The  message  service  may  retain  all  of  this  delegation  information  for  audit 
purposes.  It  is  planned  that  this  delegation  facility  will  be  extended  to  permit  a user  to 
specify  in  advance  the  criteria  tor  selecting  messages  to  be  delegated  to  others.  The 
service  will  then  automatically  perform  the  delegation  whenever  a message  meeting  these 
criteria  is  received. 

This  coordination  process  can  be  iterated  as  often  as  necessary,  with  each  version 
being  coordinated  independently.  A majoi-  IA  researrh  goal  is  to  learn  more  about  the 
staffing  process  and  about  how  to  structure  the  cor.puter-aided  environment  to  enhance 
the  effectiveness  of  this  coordination. 

The  delivery  stage  involves  conveying  the  message  to  its  ultimate  recipients, 
ar»,hiving  it,  plus  providing  aids  for  the  user  to  sort  his  messages,  scan  them,  and  file  them 
for  later  retrieval.  The  first  step  in  this  process  is  to  determine  distribution  for  the 
message.  Because  of  the  military  policy  that  all  formal  traffic  flows  between  commanders 
of  organizations,  it  is  necessary  to  employ  complex  procedures  to  determine  the  real 
ultimate  recipients.  The  IA  message  service  extends  the  normal  "one-pass"  distribution 
algorithms  provided  in  current  AUTODIN  terminals  (e.g.,  LDMX)  to  allow  each  user  to  build 
his  own  automatic  personal  distribuhon  determination.  A special  form  of  distribution 
determination  pro'-ided  by  IA,  called  Guarding,  allows  a user  to  specify  criteria  for 
messages  that  are  to  be  routed  to  the  first  "on-line"  user  on  the  guard  list.  This  assures 
that  incoming  messages  meeting  these  criteria  will  be  delivered  to  a live  person  who  can 
act  on  it  immediately. 

In  addition  to  determining  the  distribution  of  a message,  it  is  military  policy  to  assign 
one  of  the  recipients  responsibility  for  taking  whatever  action  is  appropriate.  The  officer 
assigned  the  "Action"  may  further  delegate  the  Action  to  a suhordi.iate  or  -ay  "sell  the 
action"  to  some  other  more  appropriate  officer.  The  auiomated  message  service  must 
keep  track  of  this  action  assignment  until  such  time  as  the  action  has  been  completed. 
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A different  form  of  special  handling  offered  by  lA  is  the  alerting  mechanism,  which 
allows  users  to  specify  criteria  for  messages  that  will  cause  immediate  action  on  the  user’s 
screen  when  they  are  received.  This  will  notify  the  user  of  the  event  immediately,  if  he  is 
on-line,  or  as  soon  as  he  comes  on,  if  the  event  occurred  while  he  was  off-line.  A further 
advantage  is  that  wherever  he  is  he  may  get  on-line  via  any  available  terminal. 

Message  selector  criteria  can  also  be  applied  to  incoming  messages  to  sort  them  into 
"folders"  for  the  user,  which  provides  the  electronic  analog  of  file  cabinets.  Since  the 
message  service  can  retrieve  messages  rapidly,  these  users*  folders  actually  store  only 
citations  to  messages  rather  than  the  messages  themselves,  which  reduces  the  computer 
storage  required  to  easily  manageable  size.  The  lA  Message  Service  provides  tools  for 
specifying  "key  words"  which  can  be  used  for  later  r«:trieval  of  the  message. 


Vtr.r  Support 

The  ARPANET  experience  provides  ample  evidence  that  computer  scientists  can  use 
on-line  systems  effectively  with  little  or  no  formal  training  in  their  operation.  There  are 
also  many  examples  of  systems  used  every  day  by  nonspecalists  who  have  had  intensive 
training  (e.g.,  airline  reservation  clerks).  To  be  effective,  however,  a military  message 
service  must  be  usable  by  non-computer  people  (action  officers)  with  minimal  formal 
tram  ng.  Few  officers  spend  more  than  10  percent  of  their  time  in  message-related 
functions;  moreover,  the  present  effort  requires  no  specialized  training.  No  on-line 
message  service  will  be  used  in  the  military  if  i*  is  not  virtually  self-evident  and  highly 
supportive  whenever  the  user  has  any  questions  or  difficulty.  The  lA  project  is  focusing 
on  this  problem  as  a central  research  issue. 

The  approach  chosen  to  provide  the  necessary  support  for  the  user  who  is  not  a 
trained  operator  or  a computer  specialist  is  to  interface  him  to  the  message  service 
through  an  "intelligent  front-end  process"  which  we  call  his  "Agent."  This  Agent  makes  the 
service  appear  consistent  to  the  user.  It  is  designed  to  handle  all  control  procedures  (e.g., 
editing,  help,  defaulting,  error  Handling,  context  mechanisms,  etc.)  in  the  same  place  and 
therefore  in  the  same  way  throughout  all  phases  of  the  service.  The  lack  of  such 
consistency  is  a major  source  of  difficulty  in  the  current  TENEX  message  facilities.  The 
Agent  and  its  components  are  described  in  detail  in  [2,  3,  4],  Briefly,  it  consists  of  a 
Command  Language  Processor,  a User  Monitor  (with  attendant  background  analysis 
processes),  and  a Tutor, 

Command  Lanffungr  Prorrssor  (Cl.P).  This  serves  as  the  interpreter  fr-.-  ustir  commands 
operating  frorri  a dynamic  input  string  and  provides  input  editing  functiO'.s  and  screen 
control.  To  support  (he  neophyte,  the  CLP  has  a strong  emphasis  on  error  detection, 
recovery,  and  correction.  It  also  acts  as  the  driver  for  the  rest  of  the  Agent,  calling  in  the 
User  Monitor  and  the  Tutor  when  appropriate.  The  CLP  operation  is  affected  User 
Profile  data  v/hich  provides  information  unique  to  each  user. 
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Uutr  Monitor  (UM)  and  /Inolyat  Paekoget.  The  User  Monitor  collects  data  on  user 
performance  and  provides  the  User  Profile  data  used  by  other  parts  of  the  Agent  (Tutor 
and  CLP).  Analysis  programs  process  user  performance  data  to  test  hypotheses  and 
modify  the  User  Profile. 

Tutor.  This  provides  intelligent  help  to  on-line  users  by  explaining  commands,  reporting 
errors,  introducing  new  features,  and  providing  reference  documentation.  Tutor  operation 
is  also  affected  by  the  contents  of  the  User  Profile. 

The  Agent  is  designed  to  collect  specific  data  about  the  user’s  use  of  the  service,  to 
make  certain  analyses  of  that  data  and,  on  the  basis  of  the  results,  to  recommend  changes 
in  the  way  the  user  deals  with  the  service  or  the  way  the  service  looks  to  him.  After  we 
have  gained  actual  user  experience,  we  fully  expect  to  have  to  change  the  nature  of  the 
data  collected,  the  way  it  is  structured,  and  how  it  is  analyzed.  In  this  process,  however, 
we  expect  to  learn  a great  deal  about  the  critical  parameters  of  a man-machine  interface 
and  how  to  control  them  to  maximize  the  user’s  performance  and  satisfaction. 


Reliability 

Resilience  of  the  service  is  an  important  aspect  of  a message  service.  The  ‘4 
design  calls  for  a distributed  process  across  multiple  host  processors  with  redundant 
copies  of  the  service’s  basic  files  dispersed  amo.ng  the  hosts.  If  any  one  host  is  not 
operating,  any  user  can  then  still  be  served.  Since  the  processes  are  distributed,  a user 
does  not  need  to  run  on  the  machine  which  stores  his  files. 

In  order  to  make  this  work,  file  naming  conventions  must  be  coordinated  to  insure 
system-wide  uniqueness.  In  the  lA  message  service  design  there  are  three  distributed 
processes,  each  of  hich  controls  a separate  data  base.  The  Coordination  Daemon 
controls  all  messages  in  preparation;  the  Transmission  Daemon  controls  all  messages  that 
have  been  released:  and  the  User  Daemon  controls  all  user  personal  data  files.  Every  host 
involved  in  the  service  has  a copy  of  each  of  these  daemons.  When  a user  logs  on,  he  is 
assigned  to  a host  by  the  User  Daemon.  That  host’s  daemons  retrieve  his  personal  files 
and  then  start  up  a job  for  him.  This  user  job  talks  to  the  daemons  for  all  its  subsequent 
message  file  accesses.  This  distributed  nature  of  the  lA  message  service  with  redundant 
file  storage  provides  the  robustness  required  for  a military  environment.  (Because  of  the 
cost  implied  by  such  «.  distributed  service,  this  aspect  of  the  lA  Message  Service  design  is 
not  being  implemented  for  the  Oahu  experiment.) 


Security 

Another  important  requirement  for  this  message  service  is  that  it  meet  military 
security  specifications.  Although  this  test  system  will  be  operated  at  system  high  (i.e.,  all 
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users  are  cleared  to  the  highest  level  the  system  will  carry),  with  access  restricted  to  TS 
personnel,  it  is  a test  objective  that  the  message  service  address  the  security  issue 
directly  in  its  design  principles.  Previous  research  done  by  MITRE  has  identified  the 
attributes  that  a system  must  possess  to  meet  this  criterion.  The  challenge  is  to  build  the 
service  in  such  a way  that  sorMone  can  verify  that  the  program  indeed  does  have  these 
attributes.  The  current  state  of  orogram  verification  will  not  handle  programs  of  the  size 
and  complexity  of  the  lA  system. 

The  approach  being  taken  is  to  concentrate  alt  of  the  security-relevant  code  in  a 
single,  small  module  (a  security  kernel).  If  it  can  be  shown  that  this  kernel  does  indeed 
handle  all  the  security  issues,  the  rest  of  the  code  does  not  need  to  be  verified.  The 
project  schedule  does  not  have  time  to  actually  verify  this  kernel,  but  the  system  is  being 
designed  with  a kernel  in  it,  which— given  the  proper  effort—could  be  verified.  The 
TENEX  operating  system,  on  which  the  message  experiment  will  be  run,  is  being  altered  to 
reflect  military  security,  and  is  assumed  to  be  a part  of  the  kernel. 

Privacy  (discretionary  control  of  message  access  on  criteria  other  than  security 
level)  IS  another  major  concern  in  a message  service.  The  principal  difficulty  here  is  in 
eliciting  from  the  military  a reasonable  statement  of  what  the  rules  should  be.  "Need  to 
know"  is  a highly  judgmental  quality  and  very  difficult  to  model.  The  lA  project  plans  to 
embody  access  control  mechanisms  general  enough  to  be  applied  to  a broad  set  of  models. 
The  service  will  support  author-assigned  access  control  to  annotations  associated  with 
messages  and  to  personal  files. 


Scalability 

In  the  COTCO  study  it  was  learned  that  during  the  average  day  on  Oahu,  6,000 
formal  AUTODIN  messages  are  sent  out  and  15,000  messages  received.  To  insure  that 
received  messages  get  to  the  appropriate  people  an  average  of  40  copies  are  distributed. 
The  CINCPAC  communication  center  devotes  a 24-hour-a-day  printing  press  to  this 
function.  To  handle  traffic  of  this  magnitude  in  an  on-line  system,  it  is  necessary  to 
organize  the  messages  as  efficiently  as  possible;  for  example,  when  a message  is 
"delivered,"  instead  of  making  a private  copy  for  each  recipient  (as  is  done  with  current 
ARPA  message  services),  the  lA  system  delivers  a brief  "citation"  to  the  message.  The 
user  IS  then  granted  read-only  access  to  these  central  copies  when  he  wishes  to  read  its 
contents. 

Other  design  decisions  in  the  lA  message  service  also  reflect  this  concern  for 
scalability.  The  organization  of  user  files  is  also  done  by  a central  process  (User  Daemon) 
to  compact  them  as  much  as  possible.  In  this  way,  data  relevant  to  many  users  can  be 
kept  in  the  same  TENEX  directory  rather  than  requiring  a directory  per  user.  The 
daemons  are  distributed  processes  that  operate  across  multiple  hosts  on  the  netwO'‘K  so 
that  the  service  can  grow  in  3 straightforward  way  by  expanding  the  subnet  (more  nodes 
and  more  links)  and  adding  more  message  processors. 
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Terminal  t 

A significant  part  of  the  lA  project  is  devoted  to  providing  good  human  engineering 
to  the  military  message  service.  For  the  traditional  action  officer  to  accept  it,  the  service 
must  be  easy  and  simple  to  use;  the  cutting  edge  of  this  problem  is  his  interaction  at  the 
CRT  terminal.  We  believe  it  is  therefore  critical  to  provide  two-dimensional  editing  with 
instantaneous  feedback  of  trivia!  operations,  as  though  the  user's  keystrokes  actually 
performed  the  operation  (insert  a character,  delete  a character,  move  cursor,  scroll, 
identify  a cursor  location  as  being  data  of  interest,  etc.).  Other  more  complex  operations 
are  dealt  with  as  commands  to  the  system  Agent.  For  these,  indication  that  the  command 
has  been  input  should  be  instantaneous,  but  longer  delay  in  actual  performance  of  the 
action  IS  acceptable. 

For  a message  service  test  in  which  users  are  separated  from  the  supporting  host 
by  a network,  it  is  difficult  to  supply  the  necessary  speed  of  response  unless  processing 
is  done  at  the  terminal  site.  With  this  two-stage  architecture  in  mind,  lA  has  designed  a 
front  end  process  (called  Terminal  Control)  as  a separable  module  for  handling  actions 
local  to  the  terminal.  Terminal  Control  will  be  put  into  a microprocessor  which  is  to  be 
provided  as  part  of  each  CRT  terminal  on  Oahu  (see  the  final  subsection  of  Section  7 for 
details  of  this  development). 


The  Military  Mettage  Experiment 

As  described  earlier,  the  principal  focus  of  the  lA  project  is  on  the  test  to  be  run  at 
CI^JCPAC  Headquarters  in  1977.  There  are  currently  two  other  message  services  (being 
built  by  BON  and  MIT)  addressing  this  same  test,  although  only  one  service  will  eventually 
be  used  for  the  operational  test.  In  addition  there  is  a PDP-10,  communication  equipment, 
and  terminals  to  be  procured,  installed,  and  maintained.  For  cost  considerations  a team 
from  MITRE  and  NRL  (this  will  be  a single-host  test)  is  overseeing  the  security  designs  of 
each  message  service,  while  another  individual  is  working  on  training  requirements.  A 
different  group  from  MITRE  is  developing  a Test  Plan  for  the  experiment,  including  the 
determination  of  data  collection  requirements  and  analysis  to  be  conducted. 

As  a part  of  the  Test  Plan  development  MITRE  has  generated  a Concept  of 
Operations,  which  describes  in  detail  the  operation  of  the  specific  community  of  users  that 
has  been  selected  for  this  test.  Operations  Directorate  (J3). 
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PROGRESS  TO  D/ITE 

During  the  past  year  progress  has  been  made  on  four  fronts:  understanding  the 
user  and  his  environment  better,  developing  and  presenting  the  plan  for  the  Oahu 
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experiment,  developing  the  softv'are  for  the  lA  message  service,  and  developing  the 
terminal  for  this  test. 


Umderttaniing  the  User 

As  this  test  has  been  slowly  taking  shape,  the  selection  of  the  ultimate  user 
community  has  been  narrowing,  until  late  this  spring  the  J3  staff  at  CINCPAC  was  selected. 
MITRE  personnel  have  spent  time  observing  the  operation  of  this  group  and  have  fairly 
well  identified  the  operations  these  users  currently  perform  in  their  message  handling. 
From  these,  MITRE  has  abstracted  a set  of  functions  which  the  message  service  should 
support.  Some  of  these  are  general-purpose  in  nature,  while  others  are  highly  specific  to 
this  community.  The  general  functions  called  for  match  quite  well  those  stated  as  design 
objectives  of  the  lA  design  in  various  earlier  documents  [5,  2,  6]. 

Another  aspect  of  understanding  the  user  involves  providing  the  optimum  language 
for  him  to  communicate  with  the  system.  In  1974  [3]  a methodology  was  outlined  for 
selecting  and  improving  this  language.  This  methodology  (which  we  call  protocol  analysis) 
was  tested  in  1975  [7]  using  a selection  of  computer  scientists  as  subjects.  In  February 
1976,  a protocol  analysis  test  was  conducted  in  Washington  D.C.  using  21  subjects  from 
various  naval  commands  (NAVELEX,  NAVTELCOM,  NAVCOMUNITWASH).  These  subjects 
included  senior  naval  officers,  engineers,  enlisted  personnel  and  secretaries.  The  results 
of  this  test  were  published  in  May  [8]  and  revealed  interesting  valu.ible  data.  The  test 
served  to  ascertain  how  the  users  wanted  to  be  able  to  use  the  system,  how  they  wished 
to  phrase  instructions  to  the  system,  which  functions  they  used  most  frequently,  what 
vocabulary  they  employed,  and  so  forth.  It  also  helped  in  identifying  many  necessary 
functional  requirements  of  the  service  (e.g.,  by  clarifying  the  overall  structure  of  the 
message  operation  and  the  interaction  of  its  parts).  Since  the  nature  of  formal 
communications  within  NAVELEX  and  NAVTELCOM  appears  to  be  different  from  that  in  the 
Operations  staff  at  CINCPAC,  in  July  of  this  year  a protocol  analysis  will  be  conducted  on 
Oahu  using  a representative  sample  from  the  eventual  community  of  users  in  order  to 
understand  their  specific  needs. 


Developing  the  Plan  for  the  Experiment 

Since  ISI  has  been  involved  in  this  ARPA  program  from  its  inception,  it  has 
participated  to  some  degree  m many  phases  of  its  planning.  In  January  1975,  the  lA 
project  produced  an  informal  report  to  ARPA  and  NAVELEX  called  Military  Message 
Processing  System  Design  which  outlines  our  ideas  of  how  a test  plan  should  be  organized 
and  what  it  might  contain.  Since  then  MITRE  has  been  contracted  to  develop  a formal  test 
plan,  and  the  lA  project  has  reviewed  and  critiqued  the  various  drafts  of  that  document  as 
it  has  evolved. 
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in  order  to  assist  ARPA  and  NAVELEX  in  planning  for  this  experiment,  the  project 
ha^  produced  a number  of  reports  and  documents  during  the  past  year,  including  a 
recommended  TENEX  configuration,  a study  of  potential  systems  for  use  as  the  data 
concentrator  for  the  test,  a specification  of  the  functions  and  equipment  required  for  that 
data  concentrator,  and  several  PERT  charts  for  the  system  integration  for  the  experiment. 
The  recent  i>ttention  to  security  has  required  lA  participation  in  joint  discussions  with  the 
other  message  service  developers  and  the  security  control  team  from  MITRE  and  NRL 
From  these  discussions  each  service  is  developing  its  own  approach  to  handling  security. 


Menage  Service  Development 

During  the  past  year  the  lA  message  service  has  gone  from  a design  on  paper  to  a 
near  operational  system.  From  the  start  the  service  has  been  divided  into  two  major 
phases.'  Phase  1 involved  development  of  the  Agent  and  the  creation  and  coordination 
aspects  of  the  message  service;  this  has  required  bringing  up  at  least  skeletal  versions  of 
ail  the  basic  modules  of  the  service.  Phase  2 covers  the  message  reception,  archival,  and 
retrieval  features  of  the  service.  Phase  1 is  nearly  complete,  and  Phase  2 is  under  way. 

The  parts  of  the  Agent  developed  this  year  include  the  Terminal  Simulator,  the 
Command  Language  Processor,  and  part  of  the  Tutor.  The  terminal  simulator  is 
code-resident  in  the  POP- 10,  which  is  designed  to  make  the  HP  2640A  look  to  the  user 
and  the  rest  of  the  service  like  the  new  terminal.  It  provides  multiple  windows,  with 
independent  scrolling,  local  editing,  and  function  keys.  This  simulator  is  necessary  until 
the  new  terminal  is  ready. 

The  Command  Language  Processor  (CLP)  does  the  command  interpretation  and  makes 
appropriate  calls  on  the  functional  module.  The  CLP  is  table-driven,  making  the  addition  of 
new  or  altered  commands  straightforward.  The  CLP  controls  a two-line  "command 
window"  on  the  screen;  it  provides  spelling  correction  and  automatic  completion  of 
commands  and  arguments.  All  lexemes  handled  are  compared  to  a synonym  lexicon  before 
being  parsed,  allowing  flexible  substitution  of  values. 

A help  facility  is  being  developed  as  the  first  part  of  the  Tutor.  >t  operates  on 
syntactical  entities  (terms  the  user  wants  to  know  about).  A menu  is  provided  from  which 
the  user  selects  the  nature  of  inJormation  he  wants  and  the  level  of  "verbosity"  of  the 
answer. 

The  functional  aspects  of  message  creation  and  coordination  are  provided  by  the 
Functional  Module  and  the  Message  Access  Module  of  the  user  job  and  the  Coordination 
Daemon.  The  Access  Module  deals  with  the  message  as  it  is  stored  on  file  by  the  system. 
The  Functional  Module  converts  the  commands  from  the  CLP  into  appropriate  calls  on  the 
Access  Ktodule  and  displays  the  results  on  the  terminal,  through  a submodule  called  the 
Virtual  Terminal.  The  Access  Module  shields  the  Functional  Module  from  the  detailed  file 
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representation  of  the  structure  of  a message.  The  Virtual  Terminal  shields  the  Functional 
Module  from  details  of  the  terminal  characteristics. 

The  VT,  FM,  and  Access  Module  currently  support  creation  and  coordination  of  a 
message.  An  originator  drafts  a message,  adds  comments  to  fields  as  desired,  fills  in  the 
Coordination  field  with  user  names,  and  then  sends  it  for  coordination.  The  message 
coordinator  may  then  edit  the  message  and  add  comments  of  his  own.  In  addition,  he  may 
retrieve  lower  level  information  such  as  precede’ice  assigned  to  the  message  review,  and 
whether  he  has  been  asked  to  sign  off  or  juft  edit  and  comment  on  the  message.  A 
coordinator  may  start  a sub -coordination  list  of  his  own.  The  author  may  then  compare 
coordinators*  renditions  with  his  original,  or  with  each  other,  via  split  screen  display. 

The  Functional  Module  is  associated  with  each  logged-on  user.  The  Coordination 
Daemon  controls  the  central  messages-in-progress  file,  where  all  messages  being  created 
or  in  coordination  reside.  When  a drafter  originates  a messag*',  or  a coordinator  adds  his 
changes  and  comments,  this  process  controls  writing  the  update  into  the  actual  message 
file  itself.  In  addition  the  daemon  sends  out  citations  to  users  when  they  are  due  to  be 
notified  of  a message  ready  for  review.  Currently  the  Coordination  Daemon  allows  just  a 
single  user  access  to  a message  at  one  time.  Although  it  generates  citations  for  messages, 
the  reception  phase  of  the  system  cannot  handle  them  beyond  alerting  the  user  of  their 
arrival. 


Me.uag«  Tran»mis»ion 

When  a message  has  been  reviewed  appropriately  it  is  released  for  transmissions. 
The  Coordination  Daemon  arunes  off  the  excess  renditions,  ail  comments,  and  the 
coordination  list,  and  passes  the  message  to  the  Transmission  Daemon.  This  process  is 
responsible  for  formatting  and  sending  the  resultant  message  to  its  destination. 
Eventually  for  the  message  experiment  this  will  be  the  LDMX  and  AUTODIN.  At  this  time 
the  message  is  formatted  as  an  ARPANET  message  and  given  to  the  TENEX  Mailer  process. 

Messages  received  from  the  LDMX  will  likewise  be  processed  by  the  Transmission 
Daemon  and  converted  to  the  lA  internal  form.  Recipients  will  then  be  sent  citations  for 
these  messages  and  the  Functional  Module  of  user  jobs  accesses  the  message  in  a similar 
manner  as  a message  in  coordination.  Currently  ARPANET  messages  are  processed  in  this 
manner. 


M engage  Reception 

Message  reception  on  the  lA  system  centers  around  the  concept  of  file  folders. 
Initial  citations  to  messages  arrive  from  the  daemons  and  are  placed  into  a "Pending" 
folder,  somewhat  like  a person’s  in  basket  or  mail  box.  From  the  Pending  file,  messages 
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may  be  moved  into  personal  folders  or  to  more  generally  accessible  folders— analogous  to 
read  boards  or  bulletin  boards.  Although  the  user  thinks  in  terms  of  folders  holding 
messages,  in  fact  only  limited  message  data  is  stored.  From  this  limited  data,  the  full 
message  may  be  directly  retrieved. 

The  handling  of  folders  is  done  much  like  message  handling— through  a special 
Folder  Access  Module  that  isolates  the  Functional  Module  from  having  to  know  much  about 
the  internals  of  this  file  representation.  The  Folder  Access  Module  is  being  coded  at  this 
time. 

Folders  have  a number  of  special  fields  which  dictate  how  their  entries  are  handled. 
One  field  is  an  automatic  input  filter  which  allows  messages  to  be  automatically  filed 
without  explicit  user  intervention.  A Template  field  specifies  what  fields  of  the  message 
are  stored  for  this  particular  folder  and  what  fields  or  parts  of  fields  are  displayed  when 
the  contents  are  examined.  Thus  the  folder  may  store  key  words  and  the  To  field  of  each 
message,  but  not  necessarily  display  these  to  the  user.  These  fields  can  then  be  used  for 
retrieval. 

CON^riNUINC  WORK 

The  lA  project  has  a goal  of  having  an  operational  message  service,  including 
preparation  and  reception  phases,  by  the  end  of  November  1976.  A set  of  functional 
requirements  have  been  established  by  the  Test  Director  for  the  Military  Message 
Experiment.  The  lA  message  service  will  meet  the  majority  of  these  requirements  by  that 
time. 

During  the  subsequent  four  months,  the  message  service  will  be  shaken  down  using 
the  Oahu  host  computer,  live  LDMX  traffic,  the  new  CRT  terminals,  and  friendly  military 
users.  During  this  period  user  documentation  will  be  completed  and  test  data  collection 
routines  will  be  incorporated  into  the  service.  Additional  terminals  will  be  built  and 
delivered. 

In  the  spring  of  1977,  the  emphasis  of  the  project  will  shift  from  development  and 
shakedown  to  training,  evaluation,  and  upgrading.  It  is  anticipated  that  a number  of 
specific  "structured"  tests  will  be  conducted  to  evaluate  specific  features  of  the  seivice. 
During  this  period  it  is  anticipated  that  an  ISI  representative  will  be  on-site  with  the  users 
to  assist  in  training  and  tailoring  the  service  to  the  users’  needs. 

By  approximately  July  1977  the  formal  operational  message  service  test  will  begin. 
By  this  time  the  principal  focus  of  the  project  will  be  on  user  and  system  support  and  on 
data  collection  and  analysis.  Since  this  will  be  the  first  time  unbiased  users  will  be 
operating  the  system,  this  will  be  a primary  opportunity  to  study  the  effectiveness  ot  the 
agent  in  supporting  the  nonspecialist  user. 
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INTRODUCTION 

Modern  military  command  and  control  techniques  have  created  a critical  need  for 
secure,  low-bandwidth  voice  communication  systems  which  maintain  high  speech  quality, 
operate  in  real  time,  and  permit  full  duplex  (simultaneous  in  both  directions) 
communications.  Such  systems  should  ultimately  provide  the  capability  for  conferences 
between  many  users  at  multiple  sites,  with  an  efficient  means  for  controlling  the 
conference.  If  these  systems  are  to  be  fully  secured,  digital  communication  techniques  are 
necessary  and  must  be  developed. 

Another  trend  in  military  communications  is  the  use  of  packet-switched  computer 
networks,  such  as  AUTODIN  II,  for  data  communications.  Beginning  in  the  1980s,  a large 
portion  of  the  military  computer  communications  load  will  be  handled  by  packet-switched 
networks,  made  up  of  telephone,  radio,  and  satellite  links.  A capability  for  secure  voice 
communications  over  packet-switched  networks  would  provide  an  efficient,  cost-effective 
response  to  much  of  the  secure  voice  communications  problem,  including  conferencing. 
The  high  ratio  between  peak  and  average  data  rates  for  voice  communication  makes  a 
packet-switched  network  an  ideal  communications  medium. 

A primary  objective  of  the  ARPA  Network  Secure  Communication  (NSC)  effort  is  to 
demonstrate  the  feasibility  of  secure,  high-quality,  low-bandwidth,  full-duplex  digital  voice 
communications  over  packet-switched  computer  communications  networks.  Much  of  this 
objective  has  bean  accomplished  using  the  ARPANET,  which  has  been  the  model  for  both 
military  and  commercial  packet -switched  networks. 


BACKGROUND 

The  ARPA  NSC  effort  has  been  in  progress  since  late  1973.  The  initial  tasks  were 
to  specify  a high-quality  low-bandwidth  speech  compression  algorithm,  select  a high-speed 
signal  processing  computer  which  could  execute  the  algorithm  in  real  time,  and  select  a 
host  and  operating  system  to  interface  the  processor  to  the  ARPANET. 


NETWORK  SECURE  COMMUNICATION 


54 


Linear  Predictive  Coding  (LPC)  was  selected  as  the  high-quality  low-bandwidth 
speech  compression  technique  because  it  seemed  to  represent  the  best  tradeoff  between 
computational  complexity,  bandwidth,  and  quality.  The  specific  algorithm  chosen  was  a 
MarKel  autocorrelation-type  LPC  of  order  10  using  SIFT  (Simple  Inverse  Filtering  Tracking) 
pitch  extraction  [MARKEL  721  [MARKEL  741  The  LPC  vocoder  extracts  12  parameters 
from  a 9.6- millisecond  frame  of  speech:  pitch,  gain,  and  10  K-parameters  (often  called 
reflection  coefficients).  The  12  parameters  from  each  frame  are  encoded  into  67  bits. 
About  52  frames  per  second  are  transmitted,  giving  a transmitted  bit  rate  of  about  3500 
bits  per  second.  Nothing  is  transmitted  during  periods  when  the  speaker  is  silent.  This 
system,  called  the  Phase  I system,  is  a fixed-rate,  fixed-order  system;  it  is  full-duplex 
(simultaneous  analysis  and  synthesis  of  speech). 

In  1973  a complete  survey  of  high-speed  signal  processing  computers  was  made, 
and  the  Signal  Processing  Systems  SPS-41  was  selected  to  be  used  by  the  NSC  group. 
The  SPS-41  is  a 16-bit  integer  machine  capable  of  4 million  18-bit  integer  multiplications 
per  second,  but  with  limited  program  and  data  storage  and  wire-wrapped  construction. 

The  PDP-11  was  chosen  as  the  host  (or  the  LPC  system,  running  under  the  ELF 
operating  system  developed  at  Speech  Communications  Research  Laboratory  (SCRL).  The 
PDP-1 1 is  to  act  as  a host  on  the  ARPANET  and  control  the  assembly  and  disassembly  of 
packets,  input  and  output  to  and  from  the  SPS-41,  and  the  operation  of  the  SPS-41 
itself.  It  should  be  noted  that  not  all  NSC  group  members  used  the  SPS-41  or  PDP-11; 
Lincoln  Laboratory  first  used  the  TX-2  host  and  FDP  signal  processor,  and  later  used  a 
PDP-11  with  a Lincoln  Digital  Voice  Terminal  signal  processor,  while  Culler-Harrison,  Inc. 
(CHI)  used  two  machines  of  their  own  design. 

With  the  hardware  chosen  and  the  algorithm  defined,  (he  next  step  was  twofold: 
formulation  of  a Network  Voice  Protocol  (NVP)  and  implementation  of  the  LPC  system  on 
the  SPS-41/PDP-1 1 combination.  Preliminary  specifications  for  the  NVP  were  issued  in 
June  1974  and  final  specifications  in  October  1974.  Since  implementing  the  LPC  system 
would  be  a time-consuming  task,  it  was  decided  to  test  the  NVP  initially  using  CVSD 
(Continuously  Variable  Slope  Delta  Modulation,  the  DOD  "standard"  high-rate  vocoder), 
which  is  particularly  easy  to  implement.  Therefore,  in  September  1974,  an  8-kilobit  CVSD 
system  was  used  to  test  early  versions  of  the  NVP;  this  great'y  aided  in  the  operational 
development  of  LPC,  revealing  several  problems  with  higher-than-usual  data  rates  on  the 
ARPANET  which  were  quickly  corrected.  The  first  CVSD  tests  were  held  between  ISI 
(using  the  SPS-41/PDP-1 1 system)  and  Lincoln  Laboratory  (using  their  FDP/TX-2  system). 
This  was  a critical  test  for  the  NVP,  since  the  systems  were  quite  diffe.’ent. 

After  encountering  many  SPS-41  design  problems,  ISI  brought  up  LPC  on  the 
SPS-41/PDP-1 1 combination  in  March  J974.  In  January  1976  the  first  LPC  tests  were  run 
on  the  ARPANET,  between  Lincoln  Laboratory  and  CHI.  Again  the  hardware  on  both  ends 
was  completely  different.  The  ARPA  LPC  system  met  all  its  specifications  and 
demonstrated  that  the  combination  of  low-bit-rate  speech  and  a packet-switched  computer 
network  was  an  effective  one. 
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The  next  step  in  demonstrating  the  usefulness  of  digital  speech  on  packet-switched 
networks  was  to  implement  a conferencing  system.  To  do  this  it  was  first  necessary  to 
expand  the  NVP  into  a Network  Voice  Conferencing  Protocol,  or  NVCP  [COHEN].  This  was 
done,  and  on  January  23,  1976,  a four-way  digital  conference  was  held  among  IS<,  Lincoln 
Laboratory,  CHI,  and  SRI,  using  the  standard  Phase  I LPC  algorithm.  SRI  used  software 
written  by  ISI  and  modified  slightly  for  their  system,  with  ISI’s  help. 

In  1975,  in  parallel  with  the  network  LPC  conferencing  system,  ISI  developed  e 
sophisticated  local  CVSD  conferencing  system,  called  MA-BELL,  for  experiments  in  practical 
digital  conferencing  within  the  Institute.  In  addition,  MA-BELL  is  serving  as  a development 
vehicle  for  the  development  of  a convenient,  human-oriented  user  interface  for  digital 
conferencing  systems.  Future  plans  include  expansion  of  the  CVSD  conferencing  so  that 
participants  can  also  be  connected  via  the  ARPANET. 

In  all  of  this,  ISI’s  NSC  project  has  acted  in  the  role  of  coordinator  among  the 
contractors.  The  NVP  and  the  NVCP  were  originally  drawn  up  at  ISI,  then  modified  into 
final  form  in  discussions  with  the  other  ARPA  NSC  sites.  The  SPS-Al  LPC  analysis  and  all 
the  PDP-11  support  software  were  written  at  ISI. 


/ieknou)Udgment$ 

Throughout  the  ARPA  NSC  effort,  the  cooperation  between  the  NSC  sites  has  been 
truly  exceptional,  as  has  been  the  guidance  of  the  ARPA  program  management.  Progams 
and  hardware  designs  have  been  freely  exchanged.  For  examole,  the  SPS  LPC  analysis 
was  written  at  ISI,  except  for  the  matrix  solution  subroutine  SOLVE,  which  was  written  by 
8BN,  and  synthesis  was  written  at  SRI.  Support  software  for  the  networN  voice  system 
came  from  ISI,  BBN,  SCRL,  and  SRI.  Technical  consulting  esme  from  SCRL,  BBN,  Lincoln,  and 
Utah.  Lincoln,  CHI,  and  SRI  cooperated  fully  in  b'inging  up  the  system. 


/fPPRO/iCH 

The  primary  objective  of  ISI’s  approach  to  Network  Secure  Communications  has  been 
to  develop  systems  and  techniques  which  are  as  generalized  as  possible.  The  NSC 
low-bandwidth  packet  speech  system  is  not  specific  to  any  one  vocoder,  such  as  CVSD  or 
LPC,  or  to  any  one  packet-switched  network,  such  as  the  ARPANET.  Of  course,  some 
portions  of  the  system  must  be  specific  to  the  vocoder  or  the  network  in  use;  however, 
these  portions  are  either  encapsulated  in  modules,  such  as  in  the  LPC  vocoder  drivers,  or 
could  be  c.ss!ly  adapted,  as  in  the  network  control  routines. 
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The  ISI  NSC  project  has  implemented  a conferencing  system,  called  MA-8ELL,  which 
is  presently  based  on  CVSD  and  operates  locally  between  several  offices  at  ISI.  In  the 
future  it  will  be  expanded  into  a transnetwork  conferencing  system.  Figure  6.1  illustrates 
a conference  with  four  users,  one  of  whom  acts  as  the  chairman.  The  system  control 
panel  is  shown  in  the  center  of  the  figuie,  with  three  users  using  CVSD  vocoders  plus  a 
control  box,  and  the  fourth  using  a standard  pushbutton  telephone. 

MA-BELL  can  handL  several  participants,  in  either  a point-to-p.'iint  or  a 
conferencing  mode.  Each  user  may  communicate  via  a CVSD  vocoder  (three  are  shewn  in 
Figure  6.1)  and  a control  box  (see  Figure  6.2),  or  via  any  ordinary  telephone  equipped 
with  a pushbutton  pad.  In  the  latter  case,  the  phone’s  pushbutto.ns  serve  as  the  control 
panel.  Tha  purpose  of  the  control  panel  for  the  ordinary  participant  is  to  c..<er  or  leave 
the  conference,  ask  for  or  relinquish  the  floor,  enter  a vote,  etc.  The  r.iairman’s  own 
control  panel,  in  addition  to  those  functions,  can  control  the  entire  conference,  assigning  or 
reassigning  the  floor,  inviting  participants,  initiating  a vote,  etc. 

The  chairman  can  also  control  the  conference  from  the  system  control  panel,  SCP. 
The  SCP  shows  all  the  available  information  about  the  participants,  including  a graphic 
display  of  the  connections  between  the  participants,  who  has  the  floor,  which  participants 
have  expressed  a wish  to  talk  (and  are  queued),  whether  the  current  speaker  has  been 
warned  that  he  is  about  to  lose  the  floor  to  the  next  speaker,  status  of  open  votes,  and 
other  functions. 

Conferences  are  initiated  by  the  chairman,  who  issues  the  conference-ID  and  the  list 
of  parties  allowed  to  participate.  Thereafter  each  participant  may  join  by  "dialing"  the 
right  sequence,  which  inci  ides  the  conference-ID.  As  long  as  there  are  only  two 
participants  in  a conference  (the  chairman  and  the  first  "joiner"),  no  conference  discipline 
is  enforced  and  both  can  talk  to  each  other  just  as  they  could  over  a regular 
point-to-point  connection;  when  the  third  participant  joins  in,  however,  the  conference 
discipline  is  enforced  and  the  participants  can  be  heard  only  when  they  have  the  floor. 

The  floor  assignment  is  either  manual--by  the  chairman--or  automatic.  The 
automatic  schedule,  which  is  currently  that  most  frequently  used,  takes  the  floor  away 
from  the  current  speaker  15  seconds  after  a request  is  mads  by  another  user  of  equal  or 
higher  priority.  The  current  speaker  is  warned  5 seconds  before  he  loses  the  floor. 
Inside  ISI  the  participants  usually  have  the  same  priority.  The  "behavior"  of  the 
"scheduler"  can  easily  be  modified  by  changing  the  parameters  involved  and  the  priorities 
assigned  to  each  participant. 

Control  output  to  the  participants  (like  "you  may  speak  now,"  "you  ha  e lost  the 
floor  " etc.)  are  issued  both  by  light  signals  to  »he  control  boxes  and  also  vocally  (by  use 
M ^ierecorded  messages).  Controlling  a conference  can  be  done  better  and  more  easily 
from  the  SCP  than  f'om  any  other  station,  because  all  the  information  about  the  state  of 
the  conference  is  grophically  displayed  in  an  easy-to-read  and  axiomatic  fashion. 
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Key  features  of  this  approach  to  packet  speech  are 

• Separation  of  control  messages  from  data  messages. 

• Robust  performance  in  the  event  of  lost  messages. 

• Elimination  of  the  possibility  of  deadlocks. 

• No  end-to-end  retransmission  of  data. 

• Dynamic  adaptation  to  changing  network  performance. 

e Sufficient  guaranteed  bandwidth  for  speech  with  minimum  delay. 

• Support  of  a flexible,  human-oriented  user  interface. 

All  of  these  approach  guidelines  have  been  and  are  being  followed  throughout  the 
NSC  project,  although  a few  are  very  difficult  to  achieve  in  actual  practice.  For  example, 
dynamic  adaptation  to  changing  network  performance  will  reouiie  additional  work  in  the 
network  measurements  area,  leading  to  better  short-range  measurements,  before  a truly 
dynamic  packet  speech  system  can  be  achieved. 

A similar  approach  has  been  used  in  the  choice  and  implementation  of  the  vocoders. 
The  most  important  consideration  was  the  highest  possible  speech  qu'  lity  at  relatively  low 
bandwidth,  which  led  to  the  choice  of  LPC.  While  the  present  Phase  I LPC  system 
operates  with  a fixed  output  rate  whenever  the  speaker  is  speaking,  the  Phase  II  LPC 
system  currently  being  implemented  operates  with  a variable  output  rate  depending  on 
the  speech  itself.  The  latter  system  will  exhibit  a higher  peak  rate  with  a considerably 
lower  average  rate  than  the  former,  a feature  which  is  particularly  compatible  with  a 
packet-switched  network. 

In  addition,  the  CVSD  vocoding  technique  was  also  used,  not  because  of  its  features, 
but  because  CVSD  was  chosen  by  the  DOD  as  its  standard  "high  rate"  vocoding  system. 


PROGRESS 
Conferencing  System 

Most  vocoders  in  use  are  not  linear  m the  sense  that  the  output  bit  streams 
cannot  be  added  in  any  meaningful  s<  nse.  Therefore,  a participant  with  only  ore  vocoder 
can  listen  to  only  one  speaker  at  a time.  This  does  not  allow  the  "common  air"  as  in  a 
normal  phone  conference,  and  creates  a need  for  conference  control.  Therefore,  the 
central  issue  in  conferencing  is  the  control  of  voice  data  flow  and  of  control  information 
flow. 
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F tgurt  6.2  Two  generations  of  control  boxes 


The  chairman  has  two  mam  functions;  scheduling  (floor  control)  and  directing  the 
speaker  by  talking  privately  to  him  wh  e he  speaks.  The  chairman  has  an  open  line  to  the 
speaker  at  ail  times.  This  allows  tne  chairman  to  guide  the  speaker  with  comments  like 
"Please  summarize  your  position,  since  I am  about  to  take  the  floor  from  you." 

The  voting  process  allows  a user  to  vote  (yes  or  no)  without  being  polled  or  having 
the  floor.  This  is  useful  not  only  for  voting  but  also  for  questions  put  forth  on  the  floor 
like  "any  comments’",  "any  questions?",  etc.,  since  it  saves  the  tedious  polling  which  is 
otherwise  necessary. 

In  the  future,  the  chairman  will  be  able  to  direct  that  the  conference  or  portions  of 
the  conference  be  recorded.  This  will  provide  an  on-line  coriference  transcript,  which 
acts  like  any  other  conference  participant.  All  participants  in  the  conference  will  be 
informed  that  the  conference  is  being  recorded.  Additional  safeguarf,  such  cs  allowing 
transcription  only  after  a unanimous  vote  of  the  participants,  could  also  fc  ' implemented. 


The  Network  Voice  Conference  Protocol  ^NVCP' 


The  conferencing  feature  of  NVCP  is  based  on  the  fcllowng  model: 


• Each  participant  has  only  one  vocoder  and  therefore  can  listen  to  (only)  one 
speaker  at  a time. 
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• In  each  "station*  (i.e.,  host)  participating  m the  conference,  there  is  a process 
controlling  the  access  of  all  the  local  individuals  ("extensions,"  "participants") 
involved  in  the  conference.  This  process  is  called  the  *loca‘-  conference 
controller*  (LCC). 

• There  is  one  conference  chairman,  either  one  of  the  participants  cr  a program 
(co-located  with  one  of  the  participants),  which  decides  who  is  listening  to  whom 
and  when. 

• All  the  conference  handling  is  in  addition  to  the  regular  NVP  procedures. 

The  Network  Voice  Conference  Protocol  is  only  a control  protocol,  making  use  of  the 
same  data  protocols  as  used  by  the  NVP.  In  fact,  NVCP  is  defined  as  an  extension  to  the 
NVP  coi'.trol  protocol. 

It  is  most  important  to  realize  that  the  f-IVCP  per  se  does  not  address  the  issue  of 
the  man/machine  communication  either  between  the  participants  and  the  LCC,  or  between 
the  human  chairing  the  conference,  .f  any,  and  the  CHAIRMAN  program  controlling  the 
conference.  This  issue  is  an  implementation  issue  and  does  not  belong  to  the  protocol; 
however,  some  recommendations  for  the  mar/machine  interface  are  incluood  with  the  NVP 
protocol. 

The  conference  tiructure.  During  a conference  two  logical  networks  exist:  the  first 
is  a high-bandwidth  network  carrying  the  voice  data  from  the  speaker  to  all  the  other 
participants;  the  other  is  a low-bandwidth  network  carrying  control  information  between 
each  participant  and  the  conference  chairman. 

The  first  logical  network,  the  data  (or  voice)  network,  is  dynamically  modified  as  the 
different  users  become  (and  cease  to  be)  the  speakers.  Whenever  a participant  receives 
the  floor  (i.e.,  becomes  the  new  speaker),  the  data  network  is  reconfigured  allow  data  to 
flow  from  this  participant  to  all  the  others. 

In  contrast  to  the  data  network,  *he  control  network  has  a static  structure,  since  the 
conference  chairman  does  not  change  during  the  duration  of  the  conference. 

Two  alternatives  were  examined  and  compared:  one  was  to  treat  each  individual 
participant  separately  from  the  others  in  the  same  site;  the  other  was  to  group  all 
participants  in  the  same  site  tor  optimizing  of  the  network  utilization.  No  advantage, 
except  simplification  of  some  programs,  seems  to  justify  the  first  possibility,  and  the 
advantage  in  optimizing  network  utilization  resulted  in  the  decision  to  group  all 
participants  at  the  same  site  together. 

Two  possibilities  were  considered;  negotiation  with  the  chairman  once  per 
participant,  or  once  per  host.  The  latter  was  chosen  for  better  efficiency. 
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Two  data  traffic  patterns  were  compared,  one  from  the  current  speaker  to  all  other 
sites,  and  the  second  f'om  the  speaker  to  the  chairman,  then  to  be  distributed  to  ail  sites. 
The  first  provides  better  network  utilization  and  -mailer  delays.  The  second  is  simpler, 
since  the  data  network  does  not  change  during  th;  conference  as  required  by  the  first 
method.  Again,  it  was  decided  to  sacrifice  a littU  simplicity  for  the  sake  of  network 
utilization. 

The  uter  interface  tappertei  by  the  NifCP.  The  NVCP  can  support  a user  interface 
which  allows  the  user  to  do  the  following-: 

• Oefine  a conference  (with  optional  participants  list)  to  be  chaired  by  this  user, 
or  by  any  other  participant  at  the  discretion  of  this  user. 

• Join  a conference  chaired  by  another  user  (dialing). 

• Request  the  floor. 

• Relinquish  the  floor. 

• Perform  several  functions  whose  meaning  is  defined  at  conference  time  (e.g., 
voting,  "yes"  and  "no"). 

• Terminate  his  participation. 

The  user  interface  will  also  allow  the  system  to  tell  the  participant 

• That  he  is  "in"/"out"  of  a conference. 

• That  he  may  or  may  not  talk. 

• Several  functions  to  'v'  issigned  at  conference  time  (e.g.,  "You  have  two  minutes 
to  finish  talking"). 

The  conference  orfonication.  A conference  starts  when  the  chairman  tells  his 
system  that  he  wants  to  initiate  a conference  and  defines  the  participants  list.  At  this 
stage,  a conference  chairman  control  program  is  initiated. 

Whenever  a user  wants  to  participate  in  a conference,  he  contacts  the  chairman  (via 
the  LCC)  and  discusses  :t  with  him  (using  the  NVP  negotiation  procedure).  Upon 
acceptance  of  this  user  into  the  conference,  the  chz.rman  contacts  the  LCC,  telling  it  to 
add  this  user  to  the  participants  list.  Any  active  LCC  is  always  told  by  the  chairman  from 
which  host  data  should  arrive,  on  the  link  assigned  by  this  LCC  (in  the  initial  call). 
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Wh«n  a changa  of  spaaKtr  occurs,  first  the  chairman  tells  the  speaker  that  he  does 
not  have  the  floor,  then  all  the  LCCs  are  set  to  receive  data  from  the  host  of  the  new 
speaker,  and  finally  the  host  of  the  new  speaker  is  told  to  send  data  to  all  the 
participating  hosts.  Only  after  the  L(X  finds  itself  prepared  to  ship  the  data  out  is  the 
user  notified  to  start  talking.  (Of  course,  change  of  speakers  in  the  same  site  may  be 
simpler,  since  other  hosts  do  not  have  to  change  their  receiving  procedure.)  At  any  time 
oach  participant  may  send  to  the  chairman  control  information  (e.g.,  ”1  want  to  talk  next”). 
The  chairman  may  at  any  time  send  control  information  to  any  participant. 

As  a gerteral  prirKiple,  all  control  messages  are  between  the  chairman  and  the  LCCs, 
never  directly  between  the  chairman  and  the  participants  themselves.  However,  the  NVCP 
provides  a mearts  for  direct  control  communication  between  the  chairman  and  each 
participant.  This  information  is  communicated  via  8-bit  bytes  whose  meaning  is  not 
interpreted  by  the  LCC.  This  communication  is  carried  by  special  control  messages  (e.g.,  ”1 
want  to  talk”).  Control  information  between  the  ch.-«>rman  and  the  individual  partfcipants 
that  has  to  be  understood  by  the  LCC  is  carried  by  other  messages  (e.g.,  ”please  shut  up”). 

Cemmenu.  Note  that  the  chairman  might  never  speak  if  he  so  wishes  (e.g.,  when  it 
is  an  automatic  program).  There  is  no  requirement  for  the  chairman  ever  to  send  dnta 
messages  (i.e.,  voice). 

The  chairman  may  assume  that  all  his  instructions  to  the  LCCs  are  followed  at  once. 
It  is  the  responsibility  of  tl  LCCs  which  delay  their  action  (probably  depending  on  data 
flow)  to  remain  synchronized. 

NVCP,  like  NVP,  uses  the  controlled  messages  (Type  0/0)  for  all  control  information, 
and  might  use  u’'controlled  (Type  0/3)  or  "normal"  messages  for  voice  data.  Each  vocoder 
is  expected  to  start  its  output  with  the  time-stamp  (i.e.,  parcel  number)  set  to  zero. 

Summary.  With  the  model  upon  which  our  system  is  based,  it  can  be  recognized 
that  a protocol  is  needed.  The  NVCP  provides  the  needed  facilities  for  a real-time 
packet-switched  network  conference  system. 

The  EPOS  Operating  Syitem 

One  of  the  critical  links  in  the  network/host/signal  processor  chain  which  is 
necessary  for  packet  speech  is  the  host  and  its  operating  system.  The  ELF  operating 
system,  developed  by  SCRL,  was  originally  chosen  for  the  NSC  project’s  PDP-11  operating 
system  because  it  was  originally  tailored  for  speech  applications  and  was  the  only 
.available  PDP-11  operating  system  capable  of  supporting  packet  speech. 

Both  the  initial  CVSD  and  LPC  packet  speech  systems  were  implemented  Ms.ng  ELF 
as  the  PDP-11  operating  system.  During  the  network  experiments  with  these  systems, 
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however,  it  was  'Jiscovered  that  the  PDP-11  was  very  heavily  loaded  and  that  most  of  the 
end-to-end  deliy  was  caused  not  by  the  ARPANET,  but  by  delays  within  ELF  itself.  For 
example,  sptei;h  packets  were  recopied  from  buffer  to  buffer  in  the  POP-11  several  times 
before  being  processed,  each  time  causing  additional  delay  and  overhead.  The  POP- 1 1 
was  busy  from  90  to  lOtT  percent  of  the  time  handling  one  3500  bps  LPC  vocoder,  as 
measured  by  UMSUS  utilization.  The  8000  bps  rate  of  the  initial  CVSO-based  packet 
speech  experiments  was  handled  by  an  early,  non-virtual-memory  version  of  ELF  which 
was  not  powerful  erMugh  to  handle  the  LPC  system.  Therefore,  in  order  to  handle  LPC 
conferencing,  transnet  and  local  CVSO  conferencing,  and  possible  future  applications,  the 
operating  system  was  re-designed.  The  result,  EPOS,  is  the  Environment  for  Processing  of 
On-line  Speech. 

Although  the  differences  between  EPOS  and  ELF  are  extensive,  some  of  the  major 
speed  improvements  were  accomplished  by: 

• Restructuring  system  control  blocks  to  optimize  the  code  referencing  them;  in 
particular,  the  context  switch  code  was  reduced  by  half. 

• Reducing  the  number  of  context  switches  required  in  interval  timer  handling  by 
eliminating  the  process  which  managed  the  interval  queue,  again  reducing  the 
overhead  by  more  than  one  half. 

• Using  a more  efficient  algorithm  for  inter-address-space  data  transfers,  cutting 
the  time  by  » factor  of  8 to  20. 

e Totally  re-organizing  tne  I/O  architecture  and  control  structures.  Rather  than 
having  a general  I/O  control  process  with  drivers  for  specific  devices,  EPOS  uses 
a separate  process  tor  each  device;  this  allows  the  code  to  be  specialized  for 
each  device,  so  that  fewer  instructions  are  executed  than  for  a generalized 
process.  I/O  operations  pass  less  information  because  more  is  kept  in  kernel 
control  blocks.  This  allows  passing  the  parameters  in  registers  rather  than 
copying  a block  of  information  to  the  kernel,  cutting  the  overhead  by  a factor  of 
five. 

• The  network  control  process  takes  full  advantage  of  the  capabilities  of  the  IMP 
interface  to  provide  maximum  throughput.  Specifically,  for  the  network  speech 
applications,  network  messages  are  input  and  output  to/from  the  user 
program’s  buffers,  eliminating  expensive  copying.  Probably  the  most  significant 
reduction  in  overhead  is  due  to  the  efficient  management  of  network  I/O. 
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in  addition  to  performance  improvements,  EPOS  has  a number  of  features  which 
make  it  easier  to  use: 

• System  control  blocks  are  not  statically  allocated;  rather  they  are  allocated  from 
dynamic  storage  as  they  are  needed.  This  means  that  the  system  need  not  be 
tuned  for  the  resource  requirements  of  a specific  application  at  system 
generation  time. 

• The  concept  of  a "job"  is  incorporated  into  the  kernel  of  EPOS,  rather  than  the 
EXEC  as  in  ELF.  Putting  user  programs  in  separate  jobs  allows  isolation  from 
errant  neighbors  and  facilitates  protecting  the  system  against  user  errors. 

• I/O  calls  in  EPOS  are  like  those  of  TENEX.  We  have  found  that  the  ease  of  use 
of  these  calls  has  significantly  reduced  the  time  required  to  write  application 
programs. 

In  more  detail,  EPOS  supplies  the  following  facilities  for  application  programs; 

• Process  management;  EPOS  combines  process  scheduling  and  interprocess 
communication  in  a single  signal/«ait  mechanism.  Semaphore  operations  are 
also  available.  The  system  supports  all  normal  auxilliary  functions  (process 
creation,  deletion,  freezing,  and  thawing).  This  allows  segmentation  of 
application  programs  into  multiple  processes  to  correspond  to  the  logical 
structure  of  the  task. 

• Job  Management:  A job  is  an  independent  computing  environment,  ,ch  with  its 
own  set  of  private  resources  such  as  address  spaces,  processes,  open  files,  and 
assigned  I/O  devices.  The  kernel’s  address  space  and  kernel  processes  belong 
to  job  1,  which  is  allowed  special  privileges  by  several  system  functions.  Other 
jobs  run  in  user  or  supervisor  space  and  sre  created  in  response  to  a control-C 
input  from  ary  un-ssigned  terminal. 

• Memory  management;  EPOS  allows  each  job  to  use  multiple  address  spaces  and 
to  use  separate  instruction  and  data  spares  on  rr.acli.nes  whuse  memory 
management  hardware  supports  this  feature.  "Virtual  move"  functions  allow 
transfer  of  data  between  address  spaces  within  a user  job,  or  (when  invoked  by 
kernel  functions)  between  any  address  spaces.  Page  mapping  allows  sharing 
memory  pages  and  including  particular  physical  pages  in  an  address  space.  The 
latter  feature  is  used  primarily  for  communication  with  signal  processors  through 
shared  memory, 

• I/O  management:  System  calls  handle  either  bytes  or  strings  The  latter  may 
have  a specific  length  or  may  be  delimited  by  a specified  charactci,  ;uv.h  as  a 0 
byte.  EPOS  also  supplies  asynchronous  I/O  calls,  which  do  not  block  the  calling 
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process  while  its  request  is  pending  or  in  progress.  Devices  currently 
supported  include  terminals  with  either  DLll  or  DJll  interfaces,  IMP  interfaces, 
disks,  and  MX -521  CVSD  vocoders.  Disk  I/O  is  currently  limited  to  reading  and 
writing  existing  DOS  files.  Files  opened  on  a pseudo-device  (IPP:)  become 
interprocess  ports;  this  is  the  only  means  of  communication  between  user  jobs 
which  does  not  require  doing  physical  I/O. 

e Special-purpose  hardware  support:  In  addition  to  page  mapping,  several  system 
calls  allow  user  processes  to  perform  device  manipulation  functions  for  signal 
processors  or  other  special-purpose  hardware.  User  processes  can  allocate 
interrupt  vectors  and  specify  the  contents  of  signals  to  be  issued  when  the 
interrupts  occur,  and  they  can  get  and  set  the  contents  of  particular  device 
interface  registers. 

Along  with  the  EPOS  operating  system,  the  EPOS  Exec  provides  a convenient 
environment  for  debugging  and  using  application  program.s.  The  Exec  has  external 
characteristics  almost  identical  to  the  TENEX  Exec.  It  provides  utility  services  for  loading 
and  running  programs  and  checking  their  status.  It  also  communicates  with  the  debugger 
to  allow  a user  to  change  easily  to  debugging  mode  if  a program  requires  modification  or 
repair. 

One  important  feature  of  any  programming  environment  is  a good  debugger.  All  the 
existing  PDP-11  debuggers  of  which  we  were  aware  fell  far  short  of  our  standard,  TENEX 
lODT.  Many  did  not  provide  any  symbolic  capabilities  at  all  (user-defined  symbols, 
instruction  type-in,  etc.).  Most  were  written  to  run  stand-alone  on  a PDP-11  and  would 
have  required  extensive  modifications  to  function  in  the  EPOS  multi-process  environment. 

Because  of  these  problems  and  because  we  felt  that  a powerful  debugger  was 
essential  to  enable  us  to  produce  good  software  efficiently,  we  designed  MEND,  the  Multi 
Environment  Native  Debugger.  The  design  provided  the  most  powerful  set  of  features 
provided  by  any  debugger  with  which  we  were  familiar  (including  IDDT).  Implementation 
of  MEND  has  been  approximately  75  percent  completed;  the  only  major  feature  lacking  is 
the  breakpoint  and  trace  facility,  upon  which  implementation  has  already  begun. 
Debugging  done  with  the  partially  completed  MEND  has  confirmed  that  we  have  indeed 
provided  a most  powerful  debugging  tool. 


High-Speed  Signal  Proce$ior$ 

Much  of  the  effort  spent  in  the  LPC  implementation  portion  of  the  NSC  project  was 
spent  in  isolating  and  correcting  design  problems  in  the  SPS-41  signal  processor  which 
prevented  the  LPC  programs  from  running.  The  Phase  1 version  of  LPC  consumes  about 
95  percent  of  the  SPS-41’s  time,  and  uses  13  of  the  machine’s  16  'nout/Output 
Processor  channels.  Considerable  time  and  effort  was  spent  in  adapting  algorithms  to  the 
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fixed-point  architecture  of  the  SPS.  Even  after  many  problems  were  corrected,  the 
SPS-41  was  not  reliable  enough  for  useful  demonstration  work;  therefore  it  became 
apparent  that,  in  order  to  do  high-quality  packet  speech  research  and  demonstrate  the 
results,  a more  powerful,  reliable,  easier-to-program  processor  was  required. 
Consequently,  in  late  1975,  an  evaluation  of  the  available  state-of-the-art  high  speed 
signal  processors  was  urxiertaken.  The  requirements  which  had  to  be  met  were  as 
follows: 

• High  reliability. 

• Expandability. 

• Availability  of  a simulator  written  in  a high-level  language  and  runnable  on 
TENEX. 

• Portability. 

• Floating  point  arithmetic. 

Ktere  than  10  machines  were  surveyed,  mostly  commercial  products,  with  some 
research-type  machines.  Cost,  availability,  and  capabilities  soon  narrowed  the  field  to  two 
machines.  An  effort  was  made  to  obtain  simulators  (runnable  on  TENEX)  for  both  machines 
and  write  and  run  programs  on  them  to  assess  the  relative  difficulty  of  programming  each 
machine.  A secondary  goal  was  to  estimate  the  size  and  speed  of  LPC  running  on  both 
machines.  ISI  was  able  to  obtain  the  simulator  for  one  machine,  and  implemented  the  basic 
signal-processing  subroutines  needed  for  LPC  on  that  simulator  in  a few  weeks.  That 
machine,  the  Floating  Point  Systems  AP-120B  (FPS)  was  chosen  as  the  most  suitable  signal 
processing  system. 

The  FPS  AP-120B  machine  was  delivered  to  ISI  m June  1976,  and  interfaced  to  the 
NSC  project’s  POP- 11/45.  The  Phase  I LPC  system  is  expected  to  be  operational  on  the 
FPS/PDP-11  combination  in  July  1976,  with  the  Phase  II  system  to  follow  a month  later. 
ISI’s  experience  to  date  indicates  that  the  FPS  is  reliable  and  programs  which  run  on  the 
simulator  will  run  on  the  FPS. 


Most  of  the  progress  in  the  area  of  Linear  Predictive  Coding  (LPC)  in  the  past  year 
has  been  in  LPC  conferencing  and  the  acquisition  of  a new,  reliable,  high-speed  signal 
processing  computer  (the  FPS)  and  the  implementation  of  LPC.  The  original  transnetwork 
LPC  experiments  were  conducted  in  late  FY75,  and  the  operating  Phase  I LPC  algorithm 
has  changed  little  since  then,  except  for  some  relatively  minor  quality  improvements. 
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The  major  effort  in  LPC  conferencing  involved  the  development  of  a Network  Voice 
Conferencing  Protocol  (NVCP),  wnich  is  described  in  [COCN].  The  conferencing  system 
was  brought  up  in  December  1975,  and  uses  the  standard  Phase  I LPC.  When  the 
Phase  II  LPC  is  implemented,  it  can  be  easily  installed  in  the  conferencing  system  because 
of  the  modularity  and  structure  of  the  NVCP. 

A Phase  II  LPC  system  has  been  specified  by  BBN  [VISHU].  The  Phase  II  LPC 
system  will  be  a variable-rate  system  with  a peak  rate  of  about  5500  bps  but  an  average 
rate  of  less  than  2000  bps,  compared  with  the  constant  3500  bps  output  of  the  Phase  I 
LPC  system.  Both  rates  apply  to  non-silence.  Neither  the  Phase  ! nor  the  Phase  II 
system  transmits  anything  during  silence  periods  exceeding  about  200  ms.  This  is 
achieved  by  using  a distance  measure  between  the  analysis  parameters  generated  by  the 
LPC  vocoder.  The  Phase  II  vocoder  operates  at  a fixed  frame  rate  of  about  100 
frames/second,  using  the  distance  measure  to  compare  each  frame’s  parameters  with  the 
last  set  of  parameters  transmitted.  The  new  parameters  are  transmitted  only  if  they 
differ  sufficiently  from  the  previous  ones  to  warrant  transmission. 

The  Phase  I LPC  system  has  been  implemented  and  it  being  tested  on  the  FPS 
AP-120B  signal  processor.  This  implementation  is  a special  case  of  Phase  II.  Within  a 
short  time  the  Phase  I LPC  system  using  the  FPS  will  be  operational  on  the  ARPANET, 
followed  shortly  thereafter  by  the  Phase  II  system. 

Hardware  Development 

Hardware  developed  for  MA-BELL  includes 

e An  interface  (the  PB-11)  which  allows  four  CVSD  vocoders  to  be  interfaced  to 
the  PDP-11  through  a single  DRll-C  word-at-a-time  interface. 

• A silence  detection  scheme  (based  on  one  developed  by  Lincoln  Laboratory)  was 
implemented  as  part  of  the  P8-11,  allowing  the  PDP-11  to  tell  when  a speaker 
using  a CVSD  vocoder  is  silent. 

e Two  generations  of  control  boxes  for  conference  control  and  general-purpose 
use  on  the  PDP-11  (see  Figure  6).  (Note  the  decrease  in  size  from  the  first  to 
the  second  generation.) 

e A sophisticated  telephone-answering  and  calling  system  which  allows 
general-purpose  input  and  output  from  a touch-tone  telephone  to  and  from 
the  PDP-11. 
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RESEARCH  AND  DEVELOPMENT  COALS 

The  overall  goal  of  the  NSC  project  at  ISI  is  to  provide  high-quality  research  and 
development  in  all  areas  concerned  with  digital  voice  transmission  over  packet-switched 
networks.  Specific  goals  for  future  research  and  development  activity  are 

• Further  development  of  on-line  conferencing  systems. 

• Development  of  dynamic  on-line  and  off-line  systems  for  storage,  transmission, 
and  retrieval  of  speech,  including  FTP  and  voice  message  capabilities. 

• Integration  of  speaker  authentication  and  possible  isolated  word  or  phrase 
recognition  into  all  areas  of  the  network  speech  systems. 

• Continued  attention  to  important  issues  of  efficient,  human-oriented  user 
interfaces  to  network  speech  systems. 


• Implementation  and  use  of  two  reliable  network  speech  demonstration  systems 
based  on  the  FPS  AP-120B  high-speed  signal  processing  computer. 


IMPACT 

The  NSC  effort  can  be  expected  to  have  a broad  impact  on  one  high-priority  military 
item,  secure  digital  voice  communication,  in  digital  communications  in  general,  the  NSC 
work  has  provided  the  prototype  of  a packet-switched  voice  communications  system. 
There  is  little  doubt  in  anyone’s  mind  that  at  some  point  in  the  future  all  speech 
communications  will  be  transmitted  digitally,  whether  it  be  military,  business,  or  personal 
communication.  Since  packet  switching  has  been  proved  to  be  a highly  cost-effective  and 
bandwidth-conserving  technique,  there  will  certainly  be  many  future  packet  speech 
systems.  Packet  speech  techniques  can  be  applied  to  any  digital  transmission  medium, 
whether  it  is  telephone,  radio,  satellite,  or  optical. 

There  will  be  a need  for  well-engineered  user  -.nteriaces  for  any  and  all  future 
communications  systems,  an  area  which  is  often  developed  as  an  afterthought,  particularly 
in  areas  other  than  personal  and  consumer  applications. 

Packet  speech  has  already  had  an  appreciable  impact  on  networking.  It  was  the 
first  system  on  the  ARPANET  to  require  relatively  high  bandwidth  with  low  delays  without 
rigid  error  detection  and/or  correction.  A new  type  of  message,  the  Type  3 or 

"minimum-effort"  message,  was  implemented  as  a direct  result  of  this  requirement.  The 
packet  speech  system  has  brought  improvements  in  dynamic  network  measurements  at  the 
host-to-host  level,  in  order  to  optimize  communications,  and  will  bring  about  more 
improvements  in  dynamic  network  measurements  in  the  future. 
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The  signal  processing  aspects  of  the  NSC  effort  have  already  had  a wide  impact  on 
the  speech  compression  and  military  communications  communities.  Tlie  ARPA  NSC  effort 
and  the  people  involved  in  it  have  greatly  influenced  the  low-cost  low-bandwidth  vocoder 
specified  by  the  DOO  consortium,  of  which  ARPA  was  a member.  The  LPC  algorithm  is 
serving  as  a front  end  to  authentication  systems  developed  at  SCRL  and  phrase 
recognition  systems  developed  at  Lincoln  Laboratory.  Using  the  NVP,  these  systems  can 
and  will  be  used  via  the  ARPANET.  There  will  also  be  significant  impact  on  other  areas, 
including  operating  system  design  for  systems  handling  high-bandwidth  data  such  as 
speech,  practical  low-cost  high-speed  computing  systems  using  signal  processors,  and,  of 
course,  future  network  design. 
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XEROX  GRAPHICS  PRINTER 
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Since  its  inception,  ISI  has  undertaken  several  hardware  development  efforts  in 
support  of  research  requirements  or  *o  demonstrate  a capability  for  a recognized  PoD 
application.  As  reported  in  [AR  74],  one  of  the  most  significant  of  these  projects  is  the 
development  and  use  of  the  Xerox  Graphics  Printer  (XGP),  a high-quality  document  printing 
capability  in  the  form  of  a network  terminal. 

Two  XGP  systems  have  been  instal'ed,  one  at  ARPA  and  one  at  ISI.  They  provide 
higfi-quality  on-line  hard  copy  with  proportional  spacing  of  characters  according  to  width, 
and  use  of  multiple  fonts.  This  report  is  an  example  of  the  XGP’s  capabilities. 

From  mid-1974,  when  these  systems  were  installed,  until  September  1975,  the 
components  of  the  XGP  systems  at  both  ARPA  and  ISI  consisted  of  a modified  Xerox 
machine  interfaced  to  a PDP-ll/40  with  32K  words  of  core  and  256K  words  of  dish, 
interfaced  via  a 2400 -baud  line  to  the  ARPA  TIP,  and  driven  over  the  ARPANET  by  any 
TENEX  system,  particularly  OFFICE- 1,  ISI,  and  ISIB.  See  Figure  7.1. 

During  the  last  half  of  1974  problems  with  throughput  and  user  controls  were 
uncovered.  These  problems  are  documented  in  last  year’s  annual  report  [AR  75].  To 
correct  these  problems,  a short-term  project  was  established  to  improve  these  systems. 
The  primary  improvements  are  background  queueing  and  transmission  of  files,  overlapped 
printing  and  transmission,  and  automatic  shipment  of  character  sets.  The  following  specific 
steps  were  taken: 

1.  The  connection  between  the  PDP-11  and  the  TIP  was  changed  to  use  a 
host  interface.  Corresponding  changes  in  the  software  in  the  PDP-11 
were  also  made. 

2.  Printing  and  transmission  have  been  overlapped  to  achieve  maximum 
throughput 

3.  Shipment  of  char.icter  sets  to  >he  PDP-11  is  now  performed  automs*''-ally. 
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4.  A new  foreground  program  called  XGP  has  been  written  to  repUce  the  old 
XLIST  program.  It  queues  files  for  printing  by  a new  background  process 
modeled  after  the  LPT  server 

5.  Defaults  have  beer  established  so  that  the  user  has  to  supply  only  the 
name  of  the  file  to  be  printed  to  the  XGP  program. 

6.  A new  device,  XGP:,  has  been  installed  m TENEX  so  that  users  may  output 
directly  to  the  XGP 


Connection  of  the  PDP-11  at  a Hott 

In  order  to  support  high-speed  network  transmission,  the  hardware  of  the  PDP-11 
has  been  augmented  with  a host  interface  and  enough  memory  to  support  both  the  ELF 
operating  system  and  the  XGP  program  The  total  core  on  each  PDP-11  is  now  64K 
instead  of  32X  Memory  mapping  hardware  has  also  been  added. 

The  old  software,  based  on  CMUs  PDP-11  XGP  program,  has  been  replaced  oy  a 
combination  of  VM  ELF  and  MIT's  XGP  program  Tne  VM  ELF  system  provides  network  and 
disk  I/O  and  address  space  management  MIT’s  XGP  software  is  a much  improved  version 
of  CMU’s  software,  pro/idmg  the  same  functions  of  converting  character  codes  to  raster 
lines  suitable  for  transmission  to  the  XGP  hardware 


Overlap  of  Printing  teith  Trantmitiion 

Text  received  from  the  ARPANET  is  buffered  onto  the  disk.  Printing  is  initiated 
after  the  hrst  page  has  been  received  If  transmission  is  slowed  after  printing  has  started 
and  the  printing  process  actually  catches  up  to  the  transmission,  printing  is  interrupted  at 
the  next  page  boundary.  Printing  resumes  when  sufficient  text  has  been  received. 

In  normal  cases,  throughput  of  a few  kilobits  per  second  is  all  that  is  required  to 
keep  up  with  the  printing  process.  Even  when  TENEX  is  heavily  loaded,  it  is  usually  able 
to  accomplish  this 
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/htlomation  of  Character  Set  Shipment 

The  background  TENEX  process  rww  accepts  commands  from  the  text  file  to  ship 
character  sets  to  the  PDP-11.  Correspondm®  changes  to  XQFF  to  generate  these 
commands  have  been  made  and  use  of  character  sets  is  now  cor>', rolled  entirely  by  the 
commands  m the  text  file. 


Revision  of  Core  Allocation 

The  origina.  core  allocation  scheme  m the  PDP-11  program  placed  each  new  font  m 
progressively  increasing  memory  locations.  Eventually,  memory  space  was  exhausted  and 
the  printing  process  was  aborted.  Since  only  two  fonts  are  active  at  any  one  time,  it  is 
possible  to  reuse  the  space  released  by  previously  used  fonts.  A strategy  to  reuse  the 
core  space  was  designed  and  implemented 


Esiaklit!:ment  of  Defaults  for  XCP  and  the  PDP-11 

Jeiaults  for  paper  size,  margins,  character  sets,  ^nd  tab  stops  have  been 
established  so  that  line-pnnter-type  files  print  as  much  as  possible  as  they  would  on  the 
printer. 


Queueing  of  Filet 

The  functions  of  the  original  XLIST  orogram  have  been  divided  into  two  parts.  One 
part  interacts  with  the  user  to  accept  file  names  and  destinations.  It  copies  the  file  into 
the  XGP-PRINTER  directory.  The  second  part  is  a permanent  background  task  which 
attempts  to  connect  to  the  XGP  and  sends  files  stored  m the  XGP-PRINTER  directory  to  ».ie 
designated  XGP. 


Conclusion 

This  system  became  operational  in  late  1975.  The  XGP  special  project  was 
disbanded  in  January  1976  and  maintenance  of  the  XGP  system  is  now  performed  by  the 
!SI  Systems  Group  of  which  Pete  Alfvm  is  the  principal  coo'dinator  for  the  XGP  effort. 
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The  National  Software  Works  (NSW)  is  an  ARPANET-based  distributed  operating 
system  to  provide  a uniform  computing  environment  for  software  developers.  Services 
within  the  NSW  are  provided  on  some  of  the  ARPANET  host  computers.  These  computers, 
called  Tool  Bearing  Hosts,  are  connected  logically  by  a centralized  Works  Manage''  whose 
responsibilities  include  maintaining  a single  NSW  file  system,  validating  user  rights,  and 
assigning  resources.  In  addition,  the  NSW  includes  a user  interface,  called  the  (Tont  End, 
to  give  the  working  community  access  to  the  NSW’s  procedures  and  facilities.  (See 
[Carlson  74],  [Crocker  75b],  and  [Millstt  r-  76^  (oi  ? deeper  view  of  the  NSW.) 

Our  role  m the  NSW  project  was  to  review  inchmeal  progress  and  provide 
information/consultant  service  for  the  project.  Our  task  involved  four  areas: 

• Information  and  consui'nng  service. 

• Participation  in  the  design  of  the  System  Design  Laboratory  (SX)  of  the 
Naval  Electronics  Laboratory  Center  (NELC). 

• Document  control  and  preparation. 

• NSW  system  testing. 
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Imfermatiom  ami  ComtuUimg  Saraiet 

While  th*  NSW  was  being  designifd.  we  acted  as  an  information  source  for  potential 
'ifSW  users  ar>d  other  inter  /sted  parties.  In  particular,  we  provided  seminars  to  the  U.S. 
Army  Electronics  Command  at  Fori  Monmouth,  Now  Jersey,  the  Naval  Air  Software 
Management  Advisory  Committee  (fiLASMAC)  at  the  Naval  Weapons  Center  at  China  Lake, 
and  the  System  Design  Laboratory  design  team  at  Naval  Electronics  Laboratory  Center  in 
San  Oiego.  We  also  made  presentations  at  the  t^BS/ACM/IEEE -sponsored  workshop  on 
currently  available  testir>g  tools  m Los  Angeles  April  1975  [Crocker  75a^  ai  the  meeting 
on  Twenty  Years  Of  Computer  Science  m Pisa,  ttaly  during  June,  1975  [Crocker  75bl  arxl 
at  the  October  1975  meeting  of  the  Los  Angeles  chapter  of  Sigspace. 


SDL  Detign  mitk  SKLC 

As  an  outgrowth  of  our  initial  contact  with  the  SOL  design  team  at  NELC  we  were 
asked  to  jom  their  design  effort  to  provide  NSW  expertise  after  it  became  clear  that  N5W 
was  the  appropriate  vehicle  for  their  system  As  active  participants,  we  helped  uccign 
their  initial  Operating  Capabilities  for  their  first  demonstration  system.  Later  we  helped 
write  their  preliminary  design  report  [NELC  76). 

As  part  of  this  consulting  effort  we  also  helped  produce  a requirements  list  for  their 
front-end  work  station  [Wiiczynski  76).  That  list  was  communicated  to  the  NSW 
developers  and  was  acted  upon  by  Stanford  Research  Institute  by  means  of  a change  m 
their  front -end  specifications. 


Document  Control  and  Preparation 

iSi  has  been  the  documentation  center  for  NSW.  Continuing  responsi'jility  for 
documentation  will  rest  with  Massachusetts  Computer  Associates  (MCA)  Transfer  of  the 
activity  IS  m progress.  Since  early  implementations  of  the  NSW  were  TENEX-based,  ws 
received  many  queries  from  NSW  users  about  TENEX.  To  help  these  users  we  compiled 
two  documents  as  an  introduction  to  the  TENEX  facilities  [Holg  76a,  Holg  76b]. 


AfSfT  SyMtem  Testing 

When  the  NSW  became  a usable  TENEY  *ys\am,  ISI  was  chosen  to  house  a prototype 
version  for  general  use.  Our  system  use-  helped  the  develooers  uncover  bugs.  We  also 
worked  directly  with  the  Campus  Computer  Network  people  at  UCLA  to  help  debug  the 
NSW  batch  tool  interface  to  their  IBM  360  for  programs  required  by  the  SDL  for  their  IOC 
system. 
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S.nce  wtf  were  the  first  "outsiders"  to  have  access  to  the  NSW,  we  were  also  the 
first  to  have  detailed  Knowledge  of  how  to  use  the  system.  Since  the  NSW  user  guide  was 
not  due  until  June  1976,  we  produced  one  on  our  own  indiative  [Hofg  76c}. 
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Bnekground 

A significant  part  of  th«  lA  project  (Section  5)  is  devoted  to  providing  good  human 
engineering  to  the  military  message  service.  For  the  traditional  action  officer  to  accept  it, 
the  service  must  be  easy  and  simple  to  use.  This  applies  particularly  to  his  interaction  at 
the  CRT  terminal.  Therefore,  we  believe  it  is  critical  to  provide  two-dimensional  editing 
with  instantaneous  feedbacK  from  tn>'ial  operations,  as  though  the  user's  keystroKes 
actually  performed  the  operation  (insert  a character,  delete  a character,  move  cursor, 
scroll,  iden  y a cursor  location  as  being  data  of  interest,  etc.}.  Other  more  complex 
operations  are  dealt  with  as  commands  to  the  system's  Agent.  For  these,  moication  of 
command  input  should  be  instantaneous,  but  longer  delay  m actually  performing  the  action 
IS  acceptable. 

For  a message  service  lest  where  users  are  separated  by  the  network  from  the 
supporting  host  computer,  it  is  impossible  to  supply  the  necessary  speed  of  response 
unless  processing  is  done  at  the  terminal  site.  With  this  two-stage  architecture  in  mind, 
the  lA  project  has  designed  a front  end  process  (called  Terminal  Ckjritrol)  as  a separable 
module  for  locally  handling  actions  in  the  terminal.  Terminal  Control  currently  resides  m 
TENEX,  but  it  IS  being  moved  to  a microprocessor  which  will  then  be  provided  as  a part  of 
each  CRT  terminal  on  Oahu. 

Terminal  Control  Functions 

The  Terminal  Control  manages  the  terminal  keystroke  input  ai.d  display  output.  On 
input  from  the  keyboard  the  Terminal  Control  does  local  character  buffering,  text  editing, 
break  determination  (when  to  send  the  character  buffer),  local  echo  to  the  display,  and 
text  editing  (on  the  input  character  buffer  or  the  output  display  buffer),  etc.  On  output  to 
the  terminal  it  handles  multiple  windows  (contiguous  areas  of  screen)  and  domains  (logical 
blocks  of  text  within  windows),  dynamic  formatting  of  data  in  screen  winc'ows,  buffering  of 
more  data  than  can  be  displayed  in  a window,  scrolling  of  windows,  maintenance  of  a 
logical  cursoi  address,  and  interface  to  the  rest  of  the  system.  Domains  have  properties 
assigned  them  by  their  owner  (whatever  module  created  the  display)  such  as  highlight, 
editable,  break  characters  allowed,  etc.,  which  allows  the  Terminal  Control  to  handle 
keystroke  input  differently  in  different  domains. 
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The  Terminal  Control  is  gerwral 'purpose  m nature,  so  that  it  can  be  effective  for 
other  message  services  for  this  test  arxf  for  applications  beyond  military  message  handling. 
With  appropriate  host  software,  it  will  support  a variety  of  styles  of  commarKf  language 
input  (teletype  style,  commar>d  wirxfow  style  m the  manner  of  NLS,  menu  selection  style, 
etc.)  as  well  as  two-dimensional  full  screen  editing.  An  additional  function  that  must  be 

provided  at  the  terminal  for  the  Military  Message  Experiment  on  Oahu  is  a piece  of 

hardware  that  indicates  the  security  level  at  which  the  user  is  operating  and  that  provides 
several  Keys  for  confirming  or  not  confirming  changes  to  his  level.  This  equipment,  called 

the  Security  Control  Box,  must  be  “trusted"  >n  a security  sense  and  is  therefore  not  to  be 

incorporated  into  the  terminal  microprocessor. 


Why  Thete  Funetiont  Should  Be  in  the  Terminal 

for  se'  - il  reasons,  we  believe  the  terminal  is  the  right  location  for  this  processing. 
First,  good  response  is  guaranteed.  The  blocked  nature  of  the  data  transfers  will  reduce 
network  aid  TENEX  overhead.  If  also  provides  maximum  configuration  flexibility,  since 
stand-alone  terminals  can  work  through  TIPs  or  data  concentrators  at  any  point  on  the 
network.  Last,  it  is  consistent  with  the  security  approach  being  adopted  for  the  Oahu 
test,  and  for  end-to-end  encryption,  should  that  ever  be  added  to  the  system.  The  trend 
IS  toward  more  capacity  per  dollar  invested  in  each  terminal,  so  that  even  if  this  approach 
IS  not  the  most  cost-effective  now,  we  are  confident  it  will  be  within  two  or  three  years. 


Terminal  Selection 

A study  of  available  terminals  failed  to  locate  one  with  the  desired  display 
characteristics,  and  a 64K  byte  address  space,  and  running  at  I to  10  microseconds  per 
instruction;  we  have  therefore  decided  to  use  a new  upgraded  version  of  the  HP  26A0A 
terminal,  which  conta.ns  an  8080  microprocessor  in  place  of  the  8008.  The  26A0A  was 
chosen  by  ISI  a year  ago  for  in-house  terminal  use  because  it  offered  the  best  design  and 
reliability  available  at  that  time.  In  general,  ISI  has  been  pleased  with  the  performance  of 
these  terminals. 


Plan 


The  basic  approach  for  early  deve’opment  of  terminal  software  is  to  emulate  the 
display  processor  in  P'?IM  (Section  2)  and  develop  the  bulk  of  our  software  there,  which 
has  the  advantage  of  having  available  the  powerful  creation  and  debugging  tools  of  the 
PRIM  environment.  The  major  shortcoming  of  this  approach  is  that  PRIM  has  virtually  no 
I/O,  which  is  the  terminal  microprocessor’s  major  activity.  Thus,  though  we  can  determine 
that  the  individual  programs  do  what  we  expect  them  to  do,  we  cannot  check  oui  the 
real-time  aspects  of  the  integrated  program  operation.  This  step  will  be  done  on  a 
p»ototype  terminal  v/hich  contains  all  (64K)  read/write  memory  (RAM). 
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Besides  the  major  task  of  putting  the  lermmal  Control  into  the  terminal 
microprocessor,  some  minor  hardware  changes  are  planned.  For  example,  it  is  necessary 
to  label  the  key  caps  of  all  the  function  keys  with  appropriate  mnen>onics  and  to  add 
external  circuitry  to  drive  the  Security  Control  Box. 

The  plan  calls  for  four  terminals  equipped  with  64K  of  RAM  menvory  for  development 
and  checkout  work,  then  "production*  terminals  for  the  operational  test  equipped  with  the 
proper  mix  nf  ROM  (program  store)  and  RAM  (data  and  buffer  store).  We  have  estimated 
this  split  to  be  16K  RAM  and  48K  RQM.  One  prototype  terminal  if  required  for  initial 
development  and  debugging.  Three  more  prototypes  will  then  be  produced  and  given  to 
t.he  message  service  developers  dSt,  bdN,  and  MiT).  After  the  prototype  units  have  been 
shaken  down  with  the  message  services,  "production*  terminals  will  be  made  for  the 
operational  test,  a step  which  involves  producing  24  ROM  masks  at  a high  one -time  cost 
(any  changes  m the  firmware  after  these  ROMs  have  been  made  will  be  eauaily  costly) 
Production  terminals  for  the  test  will  be  delivered  together  with  wheeled  tables  with 
folding  wings. 

The  Security  Control  Box  will  be  provided  with  approximately  four  LEOs  to  indicate 
the  level  of  security  of  the  screen. 


Progrea  to  Dale 

A specification  for  the  external  characteristics  of  the  terminal  has  been  submitted  to 
the  participants  in  the  Military  Message  Experiment.  Internal  program  specifications  have 
been  written  and  programming  begun.  A PRIM  8080  emulator  is  operating  and  several 
routines  have  been  written  and  checked  out  on  it.  ISl  is  using  a prototype  of  the  new  HP 
terminal  for  evaluation  and  initial  program  development;  this  will  be  replaced  by  an  early 
production  unit,  to  be  purchased  when  available. 
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IfVrKODUCTION 

The  iSI  ARPANET  TEr£X  service  ♦acility  is  operated  as  a development  and  service 
center  in  support  of  a broad  set  of  ARPA  projects.  It  currently  services  more  than  1000 
directories,  son'ie  of  which  are  multiplexed  by  several  users.  Approximately  95  percent  of 
the  users  access  the  fKilities  via  the  ARPANET  from  locations  extending  from  Europe  to 
Hawaii.  All  of  the  facility’s  systems  are  available  to  all  users,  whether  they  are  connected 
through  the  ARPANET  locally  or  remotely. 

The  facility  consists  of  five  Digital  Equipment  Corporation  central  processors  (one 
Ki-10,  one  KL-2040,  and  three  KA-lOs),  Bolt  Beranek  and  Newman  virtual  memory  paging 
boxes,  large-capacity  memories,  on-line  swapping  and  file  storage,  and  associated 
peripherals  (see  Figures  8.1  and  8.2).  All  systems  presently  run  under  control  of  the 
TENEX  or  TOPS-20  operating  system  (originally  developed  by  Bolt  Beranek  and  Newman), 
which  supports  a wide  variety  of  simultaneous  users. 

HARDWARE 

New  hardware  acquired  in  past  year  includes  one  additional  DEC  KL-2040 
(TOPS-20)  system  with  256K  words  of  DEC  high-speed  internal  memory  and  associated 
peripheral  devices  (Figure  8.3),  two  CALCOMP  230  disk  drives  presently  attached  to  ISIC 
for  additional  on-line  swapping  and  file  storage  capabilities,  and  a new  CALCOMP  347 
magnetic  tape  drive  which  is  shared  (as  are  all  ISI  magnetic  tape  facilities)  among  four 
TENEX  systems.  Figure  8.2  shows  the  current  ISI  facility  configuration.  Note  that  none  o‘ 
the  cent.  ::l  processors  (KA-lOs,  KL-2040,  or  KI-10)  operate  in  dut!  processor  mode. 
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Figur*  8.1  Compositt  photograph  of  eomputtr  room 
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rigure  8.2  Diagram  of  IS  I ARPANET  TENEX  servtce  facility 
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Marti  Coal*  Photo* 

Figure  View  of  computer  room  with  FL-2040  in  center  foreground. 


Instead,  the  main  Roal  of  having  the  several  systems  is  '.o  provide  a significant  increase  in 
the  availability  of  the  ISI  primary  machines:  Thus  if  one  of  the  systems  designated  as  a 
primary  machine  crashes  or  is  unavailable  because  of  hardware/software  maintenance  or 
development,  then  one  of  the  other  systems  may  be  started  as  a primary  machine  and 
service  continued  after  a brief  (15  minutes  or  less)  interruption  to  switch  the  file  storage 
media  and  one  cable. 

Also  included  within  the  TENEX  service  facility  are  one  BBN  H-516  Interface 
Message  Processor  (IMP),  one  BBN  H-316  Terminal  Interface  Processor  (TIP),  one  DEC 
PDP-11/40  and  Xerox  Graphics  Printer  (XGP),  one  DEC  PDP-11/45  with  an  SPS-41  Signal 
Processing  System  and  a Floating  Point  Systems  AP-120B  (FBS)  (configured  as  a speech 
processor),  one  microprogrammable  processor  (MLP-900)  and  several  associated 
peripheral  devices  such  as  disk,  memory,  special  ISI-developed  interfaces,  TTY’s  etc. 

Purchase  orders  have  been  submitted  for  additional  hardware,  a DEC  DN87  Universal 
Synchronous/Asynchronous  Front  End  Communications  system  that  will  allow  all  in-house 
users  to  directly  access  the  in-house  (ISIB  KI-10)  TENEX  system.  This  will  eliminate  the 
requirements  for  the  BBN-31F  TIP  at  ISI.  Delivery  of  this  communications  equipment  is 
expected  prior  to  July  31,  1976.  Thirty  days  after  delivery  the  ISI  TIP  will  be  replaced  by 
a BBN  IMP  with  four  host  ports,  which  will  allow  ISI  to  accommodate  two  additional  host 
systems  that  will  allow  additional  users  to  access  future  ISI  systems  via  the  ARPANET. 
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SOFTWARE 


During  the  ye»r  a concentrated  effort  has  been  made  to  ensure  that  all  of  the  ISI 
TENEX  service  machines  provided  the  same  level  of  systems  software.  TENEX  version 
1.34  with  some  necessary  local  modifications  was  installed,  and  the  most  recent 
subsystems  and  documentation  pKkages  were  obtained  and  released.  To  aid  in  this 
continuing  effort  of  software  maintenance  and  upgrading,  a method  for  automatically 
distributing  changes  among  all  ISI  service  machi.ies  is  now  in  the  developmental  stage  and 
will  be  implemented  in  the  near  future.  We  have  also  provided  load-leveling  across  the 
machines  in  conjunction  with  ARPA/tPTO  to  assure  reasonable  response  and  greatly 
expanded  system  utilization. 

Two  major  services,  XGP  printing  and  file  archival,  were  improved.  The  XGP  driver 
software  running  under  TENEX  and  on  the  PDP-11  was  upgraded  and  stabilized,  XOFF 
problems  were  corrected,  and  special  output  options  and  software  interfaces  were 
implemented  (see  Section  7 for  details).  This  effort  was  also  applied  to  the  ARPA  XGP  to 
bring  it  to  the  same  level  of  service,  which  facilitates  system  maintenarck.  File  archival 
changes  were  necessitated  by  incompatibilities  between  old  magtape  drives  and  the  new 
CALCOMP  magtape  system.  The  old  archive  library  was  copied  into  a new,  substantia'ily 
smaller  library,  reflecting  the  most  recent  format  changes;  this  made  the  entire  library 
accessible  to  all  ISI  TENEX  service  machines. 
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Several  members  of  the  software  group  have  been  actively  engaged  in  performing 
comparisons  of  the  TENEX  operating  systems  with  the  TOPS-20  operating  system.  Upon 
acceptance  of  the  TOPS-20  system  at  ISI,  maximum  effort  will  be  devoted  to  installation  of 
new  JSYS’s,  JSYS  traps,  features,  and  modifications  that  will  allow  the  majority  of  the 
existing  TENEX  subsystems  to  operate  under  the  TOPS-20  system.  Modifications  of  many 
of  the  existing  TENEX  subsystems  will  also  be  required  as  part  of  this  effort.  Attempts 
will  also  be  made  to  take  the  existing  ARPA  Network  Control  Protocol  in  TENEX  and,  with 
appropriate  modifications,  incorporate  it  into  the  TOPS-20  opereting  system.  This,  along 
with  a hardware  network  interface  developed,  assembled,  and  integrated  into  the  KL-2040 
hardware  by  ISI,  will  allow  the  TOPS-20  system  to  be  accessed  via  the  ARPANET. 

SUPPORT  PERSONNEL 
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ISI  provides  seven-day-a-week,  twenty-four-hour-a-day  operator,  software,  and 
hardware  support  for  the  TENEX  service  facility.  At  least  one  operator  is  physically 
on-site  at  all  times,  and  the  systems  programmers  and  computer  service  engineers  either 
are  physically  on-site  or  are  scheduled  for  one-hour  on-call  service. 
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RELIABILITY 

To  provide  required  hardware/software  preventive  and/or  corrective  maintenance 
of  the  equipment,  ISI  will  continue  scheduling  each  of  the  TENEX  ayatemc  as  "out  of 
service"  (unavaiLble  to  users)  for  seven  contiguous  hours  each  week.  The  remaining  161 
hours  of  each  week  are  intended  to  lie  devoted  entirely  (100  percent)  to  user  service. 
The  actual  long-term  up-time  for  the  network  service  machitw  has  exceeded  99  percent  of 
scheduled  up-time  for  the  last  year. 

LOCAL  PROJECT  SUPPORT 

The  TENEX  facility  has  been  used  extensively  in  support  of  local  projects.  The  ISI 
staff  makes  use  of  the  available  standard  subsystems  (e.g.,  editors,  compilers,  assemblers, 
and  utilities),  and  soma  staff  members  have  written  subsystems  and  utilities  to  support 
their  own  projects.  The  facility  also  supports  less  frequently  used  subsystems  at  the 
special  request  of  users  (e.g.,  PDP-11  cross-assemblers  and  the  DECUS  Scientific 
Subroutine  Package). 

Major  TENEX  monitor  modifications  and  a new  software  driver  package  for  support 
of  the  MLP-900  (microprogrammable  processor  originally  developed  for  the  PRIM  project) 
have  been  developed  and  verified  and  are  now  operational  on  ISID  (see  Section  2 for 
details).  These  modifications  allow  more  efficient  use  of  the  proceseor-to-processor 
communication  facilities  between  the  TENEX  operating  system  and  the  MLP-900. 
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